8. Bezpieczeństwo i Governance - RBAC, OPA, SBOM, Catalog¶

Bezpieczeństwo jest wbudowane, nie dodawane później.
Ten rozdział definiuje płaszczyznę kontroli: tożsamość, autoryzację, politykę jako kod, ochronę danych, łańcuch dostaw i audit.

8.1 Zasady (v1.0)¶

• Najmniejsze uprawnienia per narzędzie i parametr (efekty uboczne: read|write|execute).

• Jawne zatwierdzenia dla write/execute z human-in-the-loop.

• Polityka jako kod (OPA/Rego) w Gateway + admission Kubernetes.

• Separacja obowiązków: Gateway vs Agenci vs serwery MCP.

• Evidence-first: wszystkie decyzje/audyty do AstraOps i AstraCatalog.

8.2 Tożsamość i Dostęp¶

8.2.1 Tożsamości¶

• Agenci: poświadczenia klienta OIDC (client_id, client_secret / workload identity).

• Narzędzia MCP: service principals z zakresowymi tokenami (per środowisko).

• Ludzie: SSO (OIDC/SAML) mapowane na role RBAC.

8.2.2 Role (przykłady)¶

8.3 Polityka jako Kod (OPA/Rego)¶

8.3.1 Bramka Efektów Ubocznych Narzędzi (Gateway)¶

# plik: policies/agent_tools.rego
package astra.gateway

default allow = false

# Zezwalaj na odczyty dla uwierzytelnionych agentów
allow {
  input.tool.side_effect == "read"
  input.auth.actor_type == "agent"
  input.auth.role != ""
}

# Zapisy wymagają jawnej roli + flagi zatwierdzenia w kontekście
allow {
  input.tool.side_effect == "write"
  input.auth.role == "support.agent"
  input.context.approval == true
}

# Execute wymaga roli ops i flagi emergency
allow {
  input.tool.side_effect == "execute"
  input.auth.role == "ops.agent"
  input.context.change_record != ""    # id incydentu/zmiany
}

# Blokuj zewnętrzne narzędzia gdy obecne PII
deny[msg] {
  input.context.contains_pii == true
  startswith(input.tool.name, "external.")
  msg := "Narzędzie zewnętrzne zablokowane dla PII"
}

8.3.2 Klasyfikacja Danych i Egress¶

# plik: policies/data_egress.rego
package astra.egress

default permit = false
level := input.context.classification  # public|internal|confidential

permit {
  level == "public"
  input.destination in {"webhook.trustedA","webhook.trustedB"}
}

permit {
  level == "internal"
  input.destination == "slack.corp"
  not input.payload.contains_secrets
}

# domyślnie odrzuć wszystko inne

Pakuj polityki OPA i dystrybuuj przez Gateway; wersjonuj polityki w AstraCatalog.

8.4 Admission Kubernetes (Gatekeeper/PSA)¶

8.4.1 Odrzuć Uprzywilejowane i Wymuś Read-Only RootFS¶

# plik: policies/gatekeeper/deny-privileged.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata: { name: disallow-privileged }
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

# plik: policies/gatekeeper/readonly-rootfs.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPReadOnlyRootFilesystem
metadata: { name: enforce-readonly-rootfs }
spec:
  match:
    namespaces: ["astra-agents"]

Na nowoczesnych klastrach preferuj etykiety namespace Pod Security Admission (restricted) lub równoważniki OpenShift SCC.

8.5 Łańcuch Dostaw: SBOM, Podpisywanie, Pochodzenie¶

8.5.1 SBOM i Skanowanie Obrazu (CI)¶

# Wygeneruj SBOM (Syft) i skanuj (Trivy)
syft ghcr.io/org/astradesk/support-agent:${GIT_SHA} -o spdx-json > sbom.spdx.json
trivy image --exit-code 1 ghcr.io/org/astradesk/support-agent:${GIT_SHA} || true

8.5.2 Podpisz i Zweryfikuj (cosign)¶

# Podpisz
cosign sign --key $COSIGN_KEY ghcr.io/org/astradesk/support-agent:${GIT_SHA}

# Zweryfikuj w kontrolerze admission lub zadaniu deploy
cosign verify --key $COSIGN_PUB ghcr.io/org/astradesk/support-agent:${GIT_SHA}

8.5.3 Certyfikacja Catalog¶

• Prześlij SBOM, raporty skanowania, pakiet cosign do AstraCatalog.

• Bramkuj wdrożenie na Catalog Certified = true.

8.6 Sekrety i Szyfrowanie¶

• Secrets Manager (AWS Secrets Manager/KMS; OpenShift: sealed-secrets).

• Nigdy nie wbudowuj poświadczeń w obrazy lub ConfigMaps.

• W tranzycie: mTLS Gateway↔Agent↔MCP; rotuj certyfikaty.

• W spoczynku: wolumeny/buckety szyfrowane KMS; klucze per środowisko.

• Zakres tokenu: wąski, krótkotrwały; sprawdzanie audience i TTL w Gateway.

8.7 Ochrona Danych i PII¶

8.7.1 Czyszczenie Ingress (Gateway)¶

# plik: gateway/pii_scrub.yaml
filters:
  - type: email
  - type: phone
  - type: secrets
actions:
  on_detect: redact
  log_event: true

8.7.2 Allow-Lista Egress¶

# plik: gateway/egress.yaml
allowed_destinations:
  - slack.corp
  - webhook.trustedA
block_patterns:
  - "http://*"
  - "https://unknown.*"

8.8 Audytowanie i Forensics¶

• Zdarzenie audytu per wywołanie narzędzia: nazwa narzędzia, hash schematu args, efekt uboczny, hash wyniku, id zatwierdzenia.

• Korelacja śladu: x-astradesk-trace-id, x-gateway-audit-id.

• Retencja: ≥ 90d dla prod; ≥ 1r dla krytycznych zatwierdzeń (per zgodność).

• Zabezpieczenie przed zmianą: przechowuj hashe w niezmiennym logu lub append-only object storage.

• Trwały sink (ISSUE 019/039, zaimplementowane): konkretny AuditWriter stojący za tym strumieniem zdarzeń jest wybierany przez AUDIT_MODE. Domyślny tryb jsonl zapisuje plik JSON-Lines append-only (wymagany na warstwach wdrożeniowych, fail-closed przy starcie w przeciwnym razie). Jawnie włączany tryb jetstream publikuje trwale do NATS JetStream: wywołanie narzędzia z efektem ubocznym nie jest zgłaszane jako zakończone sukcesem, dopóki JetStream nie potwierdzi zdarzenia, a osobna usługa Auditor — trwały konsument typu pull w JetStream — potwierdza (ack) każdą partię dopiero po trwałym zapisaniu jej zarówno w Elasticsearch, jak i S3, z ograniczonymi ponowieniami, przekierowaniem do DLQ po ich wyczerpaniu oraz idempotentnymi kluczami zapisu, dzięki czemu redelivery nigdy nie duplikuje rekordu. Odzyskiwanie po awarii (zabicie procesu w trakcie przetwarzania → zero utraty po restarcie) zostało potwierdzone na prawdziwym kontenerze NATS JetStream w audit/evidence/39_jetstream_durable_audit.md.

sequenceDiagram
  participant AG as Agent
  participant GW as Gateway
  participant OPA as OPA
  participant OP as AstraOps

  AG->>GW: wywołaj(narzędzie,args,efekt_uboczny)
  GW->>OPA: sprawdź(polityka, kontekst)
  OPA-->>GW: decyzja(zezwól/odrzuć)
  GW-->>AG: wynik + audit_id
  GW->>OP: audit_event(audit_id, digesty)

8.9 Governance w AstraCatalog¶

• Rejestr: agenci, narzędzia, prompty, datasety, polityki (z właścicielami).

• Poziom Ryzyka: per wersja agenta (klasy danych, uprawnienia narzędzi, zatwierdzenia).

• Artefakty Wydania: wyniki eval, notatki red-team, SBOM, podpisy.

• Kill Switch: per agent → natychmiastowe wyłączenie w Gateway.

flowchart LR
  Dev[Artefakty Dev/Stage/Prod] --> Gate[Bramka Polityki]
  Gate --> Catalog[Certyfikowany?]
  Catalog -->|tak| Release[Promuj]
  Catalog -->|nie| Block[Blokuj i Powiadom]

8.10 Model Zagrożeń (szybki)¶

8.11 Minimalne Mapowanie Zgodności¶

• ISO 27001: A.9 (Dostęp), A.12 (Ops), A.14 (SDLC), A.18 (Zgodność).

• SOC 2: Kryteria zaufania Security, Availability, Confidentiality.

• GDPR: Minimalizacja danych, ograniczenie celu, logowanie dostępu, retencja.

8.12 Listy Kontrolne Operacyjne¶

• [ ] Pakiety OPA załadowane i wersjonowane; domyślne odrzucenie dla nieznanych narzędzi.

• [ ] Gatekeeper/PSA restricted wymuszony w namespace'ach.

• [ ] Obrazy podpisane i zweryfikowane; SBOM przechowywany w Catalog.

• [ ] Sekrety pobierane w runtime przez manager; rotacje przetestowane.

• [ ] Czyszczenie PII + allow-lista egress aktywne; testy syntetyczne zdają.

• [ ] Ścieżka audytu przeszukiwalna po trace_id i audit_id.

8.13 Odniesienia Krzyżowe¶

• Dalej: 9. MCP Gateway i Pakiety Domenowe

• Wstecz: 7. Monitorowanie i Operowanie

• Zobacz także: 3. Faza Planowania - akceptowalna autonomia i zakres danych