heygrc
Przewodnik

Co HIPAA sprawdza w twoim repozytorium

Większość Przepisów dotyczących bezpieczeństwa to procesy i dokumentacja. Techniczne zabezpieczenia z 45 CFR 164.312 to ta część, która pojawia się w pull request, i są one mniejsze oraz bardziej konkretne, niż ludzie się spodziewają.

Tristan RothFounder of heygrc and ISMS Copilot

  • Founder of Better ISMS
  • Built ISMS Copilot, the GRC assistant for ISO 27001 and neighboring frameworks
  • Maps framework controls to pull-request diffs in heygrc

Inżynierowie, którzy po raz pierwszy pracują z klientem z sektora ochrony zdrowia, często wyobrażają sobie HIPAA jako ogromny audyt kodu. W większości nie jest to prawda. Przepisy dotyczące bezpieczeństwa to zbiór zabezpieczeń administracyjnych, fizycznych i technicznych. Główną część programu HIPAA stanowią analiza ryzyka, polityki, kadra oraz umowy z dostawcami. Tylko część z nich zależy od tego, co robi twój kod, a znajomość tej części sprawia, że całość staje się mniej tajemnicza.

Ta strona dotyczy tej części związanej z kodem. Nie jest to określenie statusu podmiotu objętego, umowa BAA ani obietnica, że heygrc lub ISMS Copilot obsługuje ePHI.

Zabezpieczenia dotyczące kodu

Techniczne zabezpieczenia znajdują się w 45 CFR 164.312. Te, które faktycznie ulegają zmianie w pull request, to unikalna identyfikacja użytkownika (164.312(a)(2)(i)), dostęp awaryjny (164.312(a)(2)(ii)), automatyczne wylogowanie (164.312(a)(2)(iii)), szyfrowanie i deszyfrowanie (164.312(a)(2)(iv)), kontrole audytu (164.312(b)), integralność (164.312(c)(1)), uwierzytelnianie osoby lub podmiotu (164.312(d)) oraz bezpieczeństwo transmisji (164.312(e)(1)). Automatyczne wylogowanie oraz szyfrowanie/deszyfrowanie to specyfikacje, które można uwzględnić: wdrażaj je tam, gdzie jest to rozsądne i odpowiednie, lub udokumentuj, dlaczego nie, i użyj równoważnego środka. Jeśli potrafisz rozważać, kto może uzyskać dostęp do ePHI, czy aktywność jest rejestrowana, czy jest szyfrowana w spoczynku i podczas transmisji oraz czy zmiana nadal uwierzytelnia wywołującego, to rozważasz większość powierzchni związanej z kodem w Przepisach dotyczących bezpieczeństwa.

Wiele z tego, co w inżynierii wydaje się związane z HIPAA, znajduje się poza diffem: przeglądy dostępu, szkolenia pracowników, analiza ryzyka oraz podpisana umowa BAA, gdy mają zastosowanie przepisy dotyczące podmiotów współpracujących (ta ostatnia to wymagana umowa, a nie tylko dowód, że proces został przeprowadzony). Sam kod dotyczy głównie 164.312.

Zmiany, które stają się ustaleniami

Pull request, który rejestruje pełną treść żądania zawierającą dane pacjentów, może umieścić ePHI w magazynie, do którego ma dostęp więcej osób niż system źródłowy. Zmiana, która usuwa szyfrowanie z magazynu rekordów lub kieruje każdy dostęp przez wspólne konto usługi, należy do tej samej kategorii problemów: zabezpieczenie jest słabsze po scaleniu niż przed. Jeśli zostanie to złapane w PR, autor wciąż ma kontekst, aby to naprawić. Jeśli zostanie to wykryte podczas przeglądu bezpieczeństwa klienta lub śledztwa, jest to naprawa z dokumentacją.

Ta asymetria jest argumentem za sprawdzaniem powierzchni 164.312 w diffie, a nie odkrywaniem jej po tym, jak klient poprosił o dowód.

Rola heygrc i granica uczciwości

heygrc zostało zaprojektowane, aby rozpoznawać te wzorce, gdy HIPAA jest jednym z wybranych frameworków, i cytować zabezpieczenie w odpowiednim punkcie. Nie określa, czy jesteś podmiotem objętym lub podmiotem współpracującym, nie pisze twojej analizy ryzyka, nie podpisuje umowy BAA ani nie przechowuje ePHI. Ani heygrc, ani ISMS Copilot nie są podmiotem współpracującym w zakresie HIPAA dla danych klienta w tym produkcie. Użyj go jako recenzenta zmiany, a nie jako programu zgodności.