Ryzyko międzywarstwowe

Warstwy wiedzy stają się bardziej użyteczne, gdy łączą się między warstwami — osobisty kontekst informuje pracę zespołową, decyzje zespołowe informują wdrożenia aplikacyjne. Ryzykiem łączenia nie jest to, że link istnieje; jest nim to, że link pozwala na odczyt w kierunku, który nie powinien istnieć.

Asymetria kierunkowa

Trzy warstwy, trzy profile wrażliwości, trzy różne promienie rażenia w razie kompromitacji.

Warstwa osobista trzyma treść najbardziej szczegółową i najmniej zrecenzowaną — wpół uformowane opinie, prywatne obserwacje o kolegach, szkice rozumowania, osobiste notatki finansowe lub zdrowotne. Kompromitacja osobistej warstwy jednej osoby jest ograniczona do tej osoby; treść nie jest zwykle przywoływana przez inne systemy.

Warstwa zespołowa trzyma skonsolidowaną wiedzę instytucjonalną — kontekst klienta, decyzje strategiczne, wewnętrzne playbooki. Kompromitacja warstwy zespołowej ma organizacyjny promień rażenia: zdeterminowany insider z dostępem do warstwy zespołowej trzyma ekwiwalent pamięci firmy.

Warstwa aplikacyjna trzyma treść użytkownika końcowego — rozmowy z klientami, dane produktu, fakty specyficzne dla wdrożenia. Kompromitacja warstwy aplikacyjnej oznacza ekspozycję stron zewnętrznych: organizacja staje się odpowiedzialna za dane swoich klientów, nie tylko swoje własne.

Te promienie rażenia są różne. Kontrolą, która ma znaczenie, gdy warstwy się łączą, jest zatem kierunek odczytu.

Pozycja domyślna

Osobista czyta zespołową. Zespołowa nie czyta osobistej.

Uzasadnienie: kompromitacja warstwy zespołowej, która mogłaby pivotować w każdą osobistą warstwę użytkownika, zamieniłaby ograniczony incydent w katastrofalny — prywatne notatki, obserwacje i szkice myślenia każdego pracownika wystawione przez pojedyncze włamanie do systemu zespołowego. Asymetria jest uzasadniona, bo tryby awarii są asymetryczne. Odczyt z osobistej do zespołowej, w przeciwieństwie, jest ruchem, który kumuluje wiedzę bez tworzenia nowych ścieżek ataku: użytkownik może wciągnąć własne osobiste rozumowanie do koncepcji zespołowej, a koncepcja zespołowa dziedziczy osąd jej autora, nie pełny osobisty magazyn tej osoby.

Jawne promowanie jest jedynym przepływem w kierunku zespołu. Gdy osobista treść musi pojawić się w warstwie zespołowej, użytkownik świadomie ją promuje — ze świadomością, z oznaczonym autorstwem. Nie ma cichej kopii, nie ma synchronizacji w tle. Zasadą, która to egzekwuje, jest hybrydowe autorstwo: treść w każdej warstwie ma poznawalną proweniencję, a zapisy międzywarstwowe wymagają decyzji człowieka.

Dla warstwy aplikacyjnej wzorzec jest jeszcze surowszy. Aplikacyjna nie czyta zespołowej domyślnie; zespołowa czyta aplikacyjną wyłącznie po jawnej autoryzacji. Jest tak dlatego, że aplikacyjna to miejsce, gdzie żyją dane dotyczące klienta, a kompromitacja po stronie zespołu nie powinna przekładać się na ekspozycję po stronie klienta.

Przepracowany przykład

W zespołowym KMS-ie interfejs MCP jest miejscem, w którym intencja międzywarstwowa staje się egzekwowalna. Token MCP niesie zakres — która warstwa, która rola, którzy agenci są dozwoleni — a lista dozwolonych określa, dokąd token może sięgnąć. Osobisty agent może odpytywać warstwę zespołową przez odpowiednio zakresowany token; warstwa zespołowa nie ma domyślnie tokenu, który daje jej dostęp do odczytu do osobistej warstwy jakiegokolwiek użytkownika. Jeśli agent skali zespołowej potrzebuje osobistego wejścia użytkownika, agent użytkownika jawnie zapisuje je do warstwy zespołowej. Odczyt nigdy nie dzieje się w drugą stronę.

Ten sam wzorzec rozgrywa się na granicy dwóch połączonych podmiotów po przejęciu. Gdy systemy drugiej organizacji są wprowadzane do tej samej warstwy wiedzy, sensowną wartością domyślną jest to, że personel jednego podmiotu nie widzi automatycznie rekordów klientów, danych finansowych ani szczegółów operacyjnych drugiego podmiotu. Kadra kierownicza widzi oba; liderzy działów widzą własny podmiot; specyficzny dostęp międzypodmiotowy jest przyznawany przypadek po przypadku w miarę postępu integracji. To zapobiega pospolitej awarii po-akwizycyjnej, gdzie „wszyscy nagle widzą wszystko" tworzy incydent zgodności, zanim zespół integracyjny narysuje nowe granice.

Zastrzeżenia

Reguła kierunkowa ma prawdziwe napięcie z wykrywaniem sprzeczności. Jeśli warstwy osobista i zespołowa trzymają sprzeczne twierdzenia o tej samej encji — koncepcja zespołowa mówi, że wartość umowy klienta wynosi X, a osobista notatka mówi, że X został renegocjowany do Y — poprawnym zachowaniem jest oflagowanie sprzeczności. Ale wykrywanie sprzeczności wymaga, żeby jedna strona flagi widziała twierdzenie drugiej strony, przynajmniej na poziomie istnienia twierdzenia.

Zabezpieczeniem, które wdrażam, jest częściowe: sprzeczności są wykrywane przez agenta warstwy osobistej czytającego w stosunku do warstwy zespołowej, a nie w drugą stronę. Warstwa zespołowa jest informowana „osobista notatka oflagowała sprzeczność" bez informowania, jakie jest osobiste twierdzenie. Użytkownik decyduje, czy jawnie wynieść treść do warstwy zespołowej.

Jest to wystarczająco dobre dla większości użyć. Dla wdrożeń, gdzie wykrywanie sprzeczności po stronie zespołu jest strukturalnie wymagane — regulowane raportowanie, środowiska napędzane audytem — właściwym wzorcem nie jest poluzowanie reguły kierunkowej, lecz przeniesienie sprzecznego twierdzenia do warstwy zespołowej jawnie w pierwszym miejscu. Reguła kierunkowa to kształt systemu, a nie obejście dla niego.