1. Dane prywatne w KIM. Koncepcja realizacji
2. Koncepcja uproszczona
3. Realizacja
4. Tematy powiązane
1. Dane prywatne w KIM. Koncepcja realizacji
Potrzeba
Do karty indeksowej KIM dodać trzy pola o prywatnej treści. Tzn. dostępne tylko
dla uprawnionych operatorów.
Koncepcja realizacji
Szyfrowanie danych prywatnych (poufnych).
Szyfrowanie potraktowane jako ochrona danych, a uprawnienia operatora jako
sterowanie możliwością odszyfrowania i zmiany danych.
Trawers ma wielopoziomowy system uprawnień, mechanizm funkcji pozornych
i mechanizm uprawnień do zakładek, który nadaje się do takiego sterowania.
Rozbudowa kartoteki KIM
Do standardowego rekordu KIM dodać np. trzy pola:
```
POUFNE1 C 192
POUFNE2 C 192
POUFNE3 C 192
```
Dlaczego C 192 ?
Użytkownik wprawdzie wpisuje np. maksymalnie 64 znaki, ale zaszyfrowana wartośćjest dłuższa niż tekst jawny. Po dołożeniu informacji technicznych szyfrowania
i zakodowaniu wyniku np. Base64 wartość 64-znakowa może potrzebować około 120-150 znaków.
`C 192` albo nawet `C 256` daje bezpieczny zapas.
W bazie KIM byłoby:
```
Indeks: TOWAR-0001
Nazwa: Produkt XYZ
POUFNE1:
AgFz7oF9T4m6B2R8x...h1WkP9Q==
POUFNE2:
AgHc8D2mH7z0...M0Fa==
```
W bazie nigdy nie zapisujemy jawnej informacji.
To ma bardzo istotną zaletę: nawet jeśli takie pole znajdzie się w standardowym
słowniku danych, Query, CSV albo zostanie pobrane technicznie, użytkownik otrzyma
ciąg szyfrowy, a nie informację poufną.
Jest to istotne, ponieważ standardowe narzędzia Trawersa korzystają ze słownika danych,
a np. `TableGet` potrafi pobierać wskazane pola bezpośrednio z bazy.
To jest właśnie największa zaleta koncepcji szyfrowania w porównaniu do koncepcji
mechanizmu uprawnień do karty KIM i ew. zakładek w karcie KIM.
Uprawnienia
Mechanizm uprawnień prowadzi do funkcji pozornych, np.:
```
MG_KIP10 Dane poufne KIM - wpisanie
MG_KIP20 Dane poufne KIM - korekta
MG_KIP30 Dane poufne KIM - usunięcie
MG_KIP40 Dane poufne KIM - przeglądanie
```
Funkcja pozorna zapewnia oczekiwany mechanizm uprawnień. Funkcja pozorna sama nie
wykonuje operacji, lecz jej `IdProces` służy do sprawdzenia, czy operator ma prawo
wykonać czynność realizowaną 'w locie'.
Logika programu:
```
odczyt karty KIM
jeżeli operator ma MG_KIP40
POUFNE1 := Decrypt(KIM->POUFNE1)
POUFNE2 := Decrypt(KIM->POUFNE2)
POUFNE3 := Decrypt(KIM->POUFNE3)
jeżeli nie ma MG_KIP40
nie odszyfrowywać
```
Na ekranie można wtedy zrobić jeden z dwóch wariantów.
Wariant A - najlepszy: jeżeli operator nie ma `MG_KIP40`, pól w ogóle nie pokazujemy.
Wariant B - prostszy programistycznie: pola są widoczne jako pozycje,
ale wartość pokazujemy jako:
```
********************
```
Gdy oczekuje się, żeby nawet samo pole było niewidoczne, to należy wybrać A.
Zapis danych
Przy zapisie nigdy nie wpisujemy zawartości ekranu bezpośrednio do pola KIM.
Schemat:
```
Operator wpisuje:
'Umowa handlowa 17/2026'
|
v
Encrypt()
|
v
'AgFG5u8P7cx1Qj....'
|
v
KIM->POUFNE1
```
Odwrotnie przy przeglądaniu:
```
KIM->POUFNE1
|
v
sprawdzenie MG_KIP40
|
v
Decrypt()
|
v
'Umowa handlowa 17/2026'
```
Przy braku uprawnienia funkcja `Decrypt()` w ogóle nie powinna zostać wywołana.
Klucz szyfrujący
Nie wiązać klucza szyfrującego z hasłem konkretnego operatora.
Zmiana hasła operatora mogłaby też spowodować utratę możliwości odczytu starych danych.
Dostęp do Dekrypt() nadawany jest odpowiednim uprawnieniem.
Czyli użytkownik nie zna klucza kryptograficznego.
Program posiada klucz instalacji (firmy) i używa go tylko wtedy,
gdy operator ma odpowiednie uprawnienie.
Klucz powiązany jest z numerem seryjnym instancji Trawersu.
Jak szyfrować
Nie budować własnego algorytmu typu XOR, przesuwanie znaków czy zaszyfrowanie hasłem.
Użyć standardowego szyfrowania uwierzytelnionego, np. AES-256-GCM.
Dobrze, gdy przechowywana wartość zawiera:
```
wersja algorytmu
+ losowy nonce/IV
+ ciphertext
+ tag uwierzytelniający
```
Dzięki temu dwa identyczne wpisy:
```
TAJNE
TAJNE
```
nie dadzą w bazie identycznego szyfrogramu.
To ma znaczenie, jeśli ktoś ma techniczny dostęp do plików bazy.
Raporty stają się prostsze
To jest bardzo mocny argument za metodą szyfrowania zawartości pól.
Jeżeli pole `POUFNE1` zostanie przypadkiem udostępnione w Query, CSV, SOA czy raporcie,
standardowa funkcja zobaczy:
```
AgF5mPq8xB7M...
```
a nie:
```
Producent daje nam rabat specjalny 27%
```
To oznacza, że nie trzeba przebudowywać wszystkich istniejących raportów,
żeby zabezpieczyć zawartość. One po prostu nie mają funkcji odszyfrowującej.
Raport przeznaczony specjalnie dla osób uprawnionych mógłby natomiast mieć
specjalną zmienną (blok danych), np.:
```
R_POUFNE1
```
której wartość jest ustalana:
```
jeżeli operator ma MG_KIP40
R_POUFNE1 := Decrypt(...)
w przeciwnym razie
R_POUFNE1 := ''
```
Ograniczenia: wyszukiwanie i filtrowanie
Zaszyfrowanego pola praktycznie nie da się używać w standardowym
Query do wyszukiwania treści.
Czyli nie zadziała:
```
POUFNE1 zawiera 'ABC'
```
bo w bazie jest:
```
AgF84Hhs90a...
```
Dla danych naprawdę poufnych jest to zaleta a nie wada.
W kronice zmian w KIM zapisywać fizyczną wartość pola bez dekodowania.
Podsumowanie zmian
1. Dodać 2-3 pola `C192/C256` do KIM.
2. Dodać 4 `IdProces` do uprawnień.
3. Przy wyświetlaniu KIM sprawdzać prawo `MG_KIP40`.
4. Przy dopisywaniu/korekcie/usuwaniu sprawdzać odpowiednio `MG_KIP10/20/30`.
5. Przed zapisem wykonywać `Encrypt()`.
6. Po odczycie wykonywać `Decrypt()` wyłącznie dla uprawnionego operatora.
7. Nie dodawać automatycznego odszyfrowywania do słownika, Query, CSV, `TableGet`,
SOA ani standardowych raportów.
Fizycznie dane pozostają integralną częścią rekordu KIM, standardowe mechanizmy
kopiowania/backupów nadal obejmują cały KIM, a przypadkowe wyprowadzenie
pola przez raport daje jedynie szyfrogram.
Ważne: Zaprojektować starannie miejsce przechowywania klucza szyfrującego.
To w praktyce decyduje o jakości całego rozwiązania.
2. Koncepcja uproszczona
Planuję uprościć mechanizm. Są dwie funkcje pozorne: Pokaż pola i Koryguj pola. Użytkownik w karcie KIM
widzi zakładkę: Pola poufne (Pola prywatne). Wybiera zakładkę - program wyświetla ekran z trzema liniami
- gdy ma prawo, program odmawia dostępu - gdy nie ma prawa.
Gdy ma prawo, widzi wypelnione pola + klawisz F7-popraw. Gdy ma prawo do Koryguj, to może zmieniać,
usuwać zapis. Gdy nie ma prawa, to tylko ogląda.
To rozwiązanie jest spójne, proste i wystarczające. Przy trzech polach poufnych nie widzę potrzeby
rozbijania uprawnień na cztery osobne operacje.
Jedna korekta w opisie: zakładam, że chodziło o odwrotną logikę - gdy użytkownik ma prawo Pokaż pola,
program wpuszcza go na ekran; gdy nie ma tego prawa, odmawia dostępu.
Proponowałbym dokładnie taki model:
* Pokaż pola - pozwala wejść do zakładki Pola poufne i odszyfrować/wyświetlić trzy wartości.
* Koryguj pola - pozwala dodatkowo użyć `F7-Popraw`, zmieniać wartości oraz je usuwać,
czyli np. wyczyścić zawartość pola.
* Brak Pokaż pola -> po wybraniu zakładki komunikat Brak uprawnień i żadna zawartość nie jest odszyfrowywana.
* Jest Pokaż pola, brak Koryguj pola -> ekran tylko do odczytu, bez aktywnego `F7-Popraw`.
* Są oba prawa -> pełny odczyt i korekta.
Dodałbym tylko jedną zasadę techniczną: Koryguj pola powinno logicznie wymagać Pokaż pola.
Najprościej wymusić to przy nadawaniu praw albo przyjąć w programie, że `Koryguj` automatycznie
oznacza również możliwość wyświetlenia.
Nie warto dopuszczać dziwnego stanu: operator ma prawo korekty, ale nie ma prawa zobaczyć danych.
Sam ekran widziałbym tak:
```
Pola poufne
Pole 1: ........................................................
Pole 2: ........................................................
Pole 3: ........................................................
F7-Popraw
```
W trybie przeglądania wartości są jawne dopiero po odszyfrowaniu w pamięci programu.
Fizycznie w KIM nadal pozostają szyfrogramy.
To ostatnie jest istotne: kontrola zakładki zabezpiecza dostęp z interfejsu, natomiast
szyfrowanie zabezpiecza przed odczytaniem tych pól innymi standardowymi drogami,
np. raportem, eksportem, Query czy technicznym podglądem tabeli.
Dlatego zachowałbym wcześniejszą zasadę:
`KIM -> zaszyfrowane pole -> sprawdzenie prawa Pokaż pola -> odszyfrowanie -> ekran`
a przy zapisie:
`ekran -> sprawdzenie prawa Koryguj pola -> szyfrowanie -> KIM`.
Nie wprowadzałbym osobnego prawa Usuń. W przypadku pojedynczych pól usunięcie
oznacza właściwie korektę wartości na pustą, więc prawo `Koryguj pola` wystarcza.
Jedyna rzecz, którą rozważyłbym jeszcze od strony ergonomii: sama zakładka może być
widoczna dla wszystkich, tak jak w propozycji, a dopiero wejście powoduje kontrolę prawa.
To jest prostsze programistycznie. Pierwotny wymóg klienta mówił wprawdzie,
że nieuprawniony użytkownik nie powinien widzieć nawet samego pola,
ale zakładka z nazwą Pola poufne nie ujawnia ani nazw, ani wartości tych pól.
Moim zdaniem jest to rozsądne uproszczenie.
Czyli docelowo otrzymujemy niewielką modyfikację Trawersa:
3 pola KIM + szyfrowanie/odszyfrowanie + jeden ekran + 2 funkcje pozorne.
To wygląda na dużo lepszy stosunek bezpieczeństwa do zakresu zmian niż pierwsza
koncepcja z osobną kartoteką.
3. Realizacja
Wykorzystano mechanizm uprawnień do zakładek
Karta KIM > F2-cd. > Opisy, Daty, FOR, Akcyza
...
...
Dane prywatne
Dane prywatne (zakładka)
o-Wyświetlanie MG_KKI25 <--- Uprawnienie do wyświetlenia (oglądania)
|-Korekta MG_KKI26 <--- Uprawnienie do korygowania (zmieniania / usuwania)
3 pola szyfrowane
POUFNE1, POUFNE2, POUFNE3 C 140
Dane zaszyfrowane algorytmem AES256
Treść jawna ma max 64 znaki. Po zaszyfrowaniu max 140