Wersja robocza v1.0

Autorzy: Zespół ds. bezpieczeństwa i inżynierii Energent.ai

Streszczenie

Energent.ai oferuje agenta wirtualnego pulpitu zasilanego sztuczną inteligencją, który automatyzuje złożone przepływy pracy z wieloma aplikacjami dla użytkowników korporacyjnych. Ponieważ agent operuje na wrażliwych danych biznesowych i może mieć szerokie uprawnienia na pulpitach użytkowników oraz zasobach w chmurze, bezpieczeństwo i prywatność są fundamentem naszego projektu produktu. Niniejszy dokument przedstawia model zagrożeń, architekturę obronną, środki bezpieczeństwa oraz postawę zgodności platformy Energent. Jest on oparty na strukturalnym, opartym na danych podejściu użytym w białej księdze CambioML AnyParser i jest zgodny z najlepszymi praktykami AWS Well-Architected Security Pillar oraz wytycznymi kontroli bezpieczeństwa NIST SP 800-53 Rev 5.

Spis treści

1. Wprowadzenie
2. Architektura platformy Energent
3. Model zagrożeń
4. Środki bezpieczeństwa
5. Zgodność i zarządzanie
6. Bezpieczeństwo operacyjne
7. Opcje wdrożenia dla klientów
8. Podsumowanie
9. Aneks A – Mapowanie kontroli
10. Bibliografia

1 Wprowadzenie

1.1 Cel

Dokument ten umożliwia zespołom ds. bezpieczeństwa, IT i zgodności ocenę, czy Energent.ai spełnia ich organizacyjne wymagania dotyczące bezpieczeństwa. Szczegółowo opisuje, jak chronimy dane, systemy i użytkowników przez cały cykl życia agenta, od rozwoju po operacje produkcyjne.

1.2 Zakres

• Energent Cloud (SaaS). Usługa wielo‑najemcza obsługiwana przez Energent.ai na AWS.
• Chmura prywatna / Izolacja VPC. Dedykowany stos jedno‑najemczy wdrożony w koncie kontrolowanym przez klienta na AWS, Azure lub GCP.
• On-Prem/VM. Obraz VM Linux z izolacją powietrzną dla ściśle regulowanych środowisk.

1.3 Odbiorcy

CISOs, architekci bezpieczeństwa, inżynierowie DevOps, audytorzy oraz profesjonaliści ds. zakupów oceniający Energent.ai.

2 Architektura platformy Energent

2.1 Wysokopoziomowe komponenty

Rysunek 1. Logika widoku komponentów Energent i granic zaufania.

2.2 Zasady bezpieczeństwa w projektowaniu

1. Najmniejsze uprawnienia i mikrosegmentacja. Role IAM i grupy zabezpieczeń ograniczają każdą usługę do minimalnych wymaganych uprawnień.
2. Szyfrowanie end-to-end. TLS 1.2+ dla danych w tranzycie; AES-256-GCM dla danych w spoczynku z użyciem kluczy zarządzanych przez KMS.
3. Niezmienna infrastruktura. Wszystkie węzły obliczeniowe są odbudowywane z podpisanych AMI; brak zmian na miejscu.
4. Automatyzacja ciągłej zgodności. Ochronne zasady zakodowane w IaC i reguły AWS Config do wykrywania dryfu.

3 Model zagrożeń

3.1 Aktywa

• Poświadczenia użytkowników i tokeny API
• Artefakty przepływu pracy (zrzuty ekranu, dane wyodrębnione, wygenerowane dokumenty)
• Własnościowa logika przepływu pracy

3.2 Przeciwnicy i ich zdolności

3.3 Granice zaufania

• Izolacja najemców między stosami klientów.
• Rozdzielenie między płaszczyzną kontrolną a płaszczyzną danych.
• Piaskownica w VM vs. środowisko hosta.

4 Środki bezpieczeństwa

4.1 Tożsamość, uwierzytelnianie i autoryzacja

• SSO przez SAML 2.0 / OIDC z wymuszeniem MFA.
• Polityki ABAC IAM o drobno‑szczegółowym poziomie dla wszystkich mikroserwisów.
• Dostęp uprzywilejowany w trybie just-in-time (JIT) z automatycznym wygaszeniem.

4.2 Bezpieczeństwo sieci i infrastruktury

• Bramy wyjściowe tylko do VPC; brak publicznych load balancerów w trybie chmury prywatnej.
• Cały ruch API kończy się na AWS ALB z WAF WebACL (reguły OWASP Top 10).
• Opcjonalne prywatne połączenie przez AWS PrivateLink lub VPN klienta.

4.3 Ochrona danych

• Szyfrowanie po stronie serwera (SSE-KMS) dla S3; dostępne SDK do szyfrowania po stronie klienta.
• Szyfrowanie na poziomie pól dla PII/PHI z użyciem AES-256 + kluczy opakowujących.
• Automatyczna rotacja kluczy i CMK dla każdego najemcy.

4.4 Bezpieczeństwo aplikacji

• Standardy bezpiecznego kodowania (OWASP ASVS L2).
• Zautomatyzowane pipeline'y SCA, SAST i DAST zintegrowane z CI/CD.
• Blokady zależności z weryfikowanymi podpisami PyPI/npm.

4.5 Zarządzanie sekretami i kluczami

• Sekrety przechowywane w AWS Secrets Manager z automatyczną rotacją.
• Agenci pobierają tokeny sesji o ograniczonym czasie za pomocą STS AssumeRole, nigdy długoterminowych kluczy.

4.6 Bezpieczny cykl życia rozwoju

• Modelowanie zagrożeń dla każdego epiku (metodologia STRIDE).
• Przeglądy kodu wymagają zatwierdzenia przez dwie osoby i przejścia przez bramki bezpieczeństwa.
• Reprodukowane kompilacje z pochodzeniem Sigstore.

5 Zgodność i zarządzanie

5.1 Model wspólnej odpowiedzialności

Energent przyjmuje podejście wspólnej odpowiedzialności AWS, w którym AWS zabezpiecza podstawową chmurę „chmury,” a Energent zabezpiecza wszystko „w chmurze.”

5.2 Certyfikaty audytowe (w trakcie 2025)

5.3 Mapowanie kontroli

Aneks A zawiera szczegółowe mapowanie kontroli Energent do rodzin NIST SP 800-53 Rev 5 (AC, AU, SC, SI itp.).

6 Bezpieczeństwo operacyjne

6.1 Monitorowanie, wykrywanie i reakcja

• Centralna agregacja logów w Amazon OpenSearch z niezmiennymi kopiamip zapasowymi S3.
• GuardDuty, Inspector i Security Hub umożliwiają ciągłe wykrywanie zagrożeń.
• Zespół ds. reagowania na incydenty bezpieczeństwa (SIRT) dostępny 24/7 z dokumentowanymi podręcznikami.

6.2 Zarządzanie podatnościami i testy penetracyjne

• Cotygodniowe skany obrazów kontenerów; krytyczne CVE łatanie w ciągu 24 godzin.
• Coroczne testy penetracyjne przeprowadzane przez strony trzecie oraz testy zlecone przez klientów.

6.3 Ciągłość działania i odzyskiwanie po awarii

• Wszystkie dane trwałe przechowywane w multi-AZ, wersjonowane S3 z replikacją międzyregionową.
• RPO ≤ 15 minut, RTO ≤ 1 godzina dla krytycznych usług.

7 Opcje wdrożenia dla klientów

7.1 Energent Cloud (SaaS)

• Domyślna opcja; najszybsze wdrożenie; dziedziczy bezpieczeństwo globalnej infrastruktury AWS.

7.2 Chmura prywatna / Izolacja VPC

• Stos Energent wdrożony przez Terraform w koncie AWS klienta, z kontrolą lokalizacji danych.

7.3 On-Prem / Tylko VM

• Obraz VM zdolny do pracy offline; wsparcie dla atestacji sprzętowego zaufania przez TPM/SGX.

8 Podsumowanie

Energent.ai łączy inżynierię obrony w głębi, rygorystyczne procesy operacyjne i przejrzystą zgodność, aby chronić dane klientów na każdym poziomie. Przestrzegając wiodących w branży ram, takich jak AWS Well-Architected i NIST SP 800-53, dostarczamy platformę, która umożliwia bezpieczną, skalowalną automatyzację bez kompromisów w zakresie zaufania użytkowników.

Aneks A – Mapowanie kontroli (wyciąg)

Pełna macierz dostępna na życzenie.

Bibliografia

1. AWS Well-Architected Framework – Security Pillar, 6 listopada 2024
2. NIST SP 800-53 Rev 5, „Kontrole bezpieczeństwa i prywatności dla systemów informacyjnych i organizacji,” wrzesień 202
3. CambioML i Epsilla, „Osiągnięcie 2× dokładności w pozyskiwaniu wiedzy z wykresów i tabel,” 2 sierpnia 2024