NIS2 rozšiřuje rozsah a důslednost cybersecurity povinností v EU, nutí organizace přijmout silný governance, risk management a incident response. Legal tech platformy manipulují citlivá data a musí implementovat zero-trust architektury, secure SDLC a robustní runtime kontroly pro dosažení odolnosti a audit readiness.

NIS2 připravenost

Rozsah

- Určit kvalifikaci jako essential nebo important entita; mapovat subsidiaries a kritické závislosti. - Inventura kritických služeb podporujících právní operace (DMS, e-filing, identita, AI drafting).

Risk management a governance

- Ustanovit risk management framework pokrývající policies, asset management, vulnerability handling, supply chain a incident handling. - Board-level accountability s definovanými KPI a reporting kadencí; trénink pro executives.

Reportování

- Implementovat early-warning mechanismy; definovat incident prahy a reporting timeline. - Udržovat incident evidence kits: logy, časové osy, komunikace a decision záznamy.

Zero-trust pilíře

Identity-first přístup

- Silná, kontinuální autentifikace s phishing-resistant MFA; device posture vynucena. - Fine-grained autorizace pomocí ABAC; krátkodobé credentials; just-in-time přístup pro elevated úkoly.

Mikrosegmentace

- Segmentovat workloady podle citlivosti a funkce; blokovat east-west traffic defaultně. - Service-to-service autentifikace a šifrování; implementovat identity-aware proxy.

Kontinuální verifikace

- Policy engines evaluují uživatelské, device a workload signály; session risk-based re-autentifikace. - Telemetry-driven anomaly detection; karanténa podezřelých sessions.

Secure SDLC se supply chain integritou

SBOM a dependency hygiena

- Generovat SBOM per build; monitorovat CVE; vynucovat policy pro blokování buildů s kritickými vulnerabilities.

SLSA levels a atestace

- Posunout směrem k SLSA Level 3+ s hermetic builds, provenance atestacemi a tamper-evident pipeline.

Secrets a podepisování

- Uložit secrets v HSM-backed KMS; rotovat automaticky; podepsat artifakty a container images; ověřit při admission.

Threat modeling

- Threat modely pro core služby (DMS, identita, AI); aktualizovat s architektonickými změnami.

Secure code praktiky

- Statická a dynamická analýza; IaC scanning; e2e testy zahrnující security assertions; automatizace v PR gates.

Runtime ochrana

Kubernetes hardening

- Baseline na CIS; omezit hostPath; vynucovat read-only root FS; běžet jako non-root; drop capabilities; nastavit seccomp/apparmor. - Admission control s policy-as-code (např. OPA/Gatekeeper nebo native policies); deny defaultně.

Network a egress kontrola

- Zero egress defaultně; allowlist destinace; DNS logging; proxy outbound s identity tagging.

Observabilita

- Centralizované logování; trace ID napříč službami; real-time detekce pro privilege escalations a lateral movement.

Patch a vulnerability management

- Automatizované image rebuilds a rollouts; sledovat time-to-remediate SLA; emergency patch playbooks.

Incident response a ransomware odolnost

Připravenost

- Incident runbooky pro běžné scénáře; tabletop exercises; crisis communications plány.

Immutable zálohy

- 3-2-1 strategie s offline a immutable kopiemi; testovat restores čtvrtletně; backup integrity checks.

DR testování

- Pravidelné failovery; měřit RTO a RPO; chaos engineering pro validaci předpokladů.

Právní koordinace

- Zachovat evidenci; counsel zapojení od začátku; sladit notifikace s regulatorními timeline.

Control mapping na ISO 27001/27701 a SOC 2

Control harmonizace

- Postavit jednotný control set; mapovat NIS2 požadavky na ISO Annex A a SOC 2 Trust Criteria.

Evidence management

- Evidence-as-code: uložit policies, screenshoty, logy a atestace s metadaty a retention policies.

Audit streamlining

- Připravit auditor-ready views; propojit kontroly s telemetrií a tickets; zajistit continuous compliance monitoring.

Implementační runbook

Fáze 1: Baseline kontroly

- Identity hardening, MFA rollout, baseline network segmentace, log centralizace.

Fáze 2: Supply chain integrita

- SBOM generace, vulnerability SLA, artifact podepisování a verifikace.

Fáze 3: Runtime obrany

- Policy admission controllers, egress kontroly, Kubernetes hardening, runtime detekce.

Fáze 4: Odolnost

- Immutable zálohy, DR drilly, incident response automatizace; sledovat KPI a board reporting.

Metriky a výsledky

- 90%+ snížení lateral movement cest díky mikrosegmentaci. - P95 service latency impact pod 5% z security kontrol s tuned policies. - RTO/RPO v rámci business SLA; čtvrtletní DR test pass rate nad 95%. - Audit cycle čas snížen o 30-50% přes control mapping a evidence automatizaci.

Příklad implementace: Zero-trust network policy

```yaml

Kubernetes NetworkPolicy pro legal document service

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: legal-docs-zero-trust namespace: legal-platform spec: podSelector: matchLabels: app: legal-document-service policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: name: api-gateway - podSelector: matchLabels: app: auth-service ports: - protocol: TCP port: 8080 egress: - to: - namespaceSelector: matchLabels: name: database ports: - protocol: TCP port: 5432 - to: - namespaceSelector: matchLabels: name: logging ports: - protocol: TCP port: 443 ---

OPA Gatekeeper policy pro security baseline

apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8ssecuritybaseline spec: crd: spec: names: kind: K8sSecurityBaseline validation: properties: excludedImages: type: array items: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8ssecuritybaseline violation[{"msg": msg}] { container := input.review.object.spec.containers[_] container.securityContext.runAsUser == 0 msg := "Container nesmí běžet jako root" } violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.readOnlyRootFilesystem msg := "Container musí mít read-only root filesystem" } ```

Supply chain security příklad: SLSA implementace

```yaml

GitHub Actions workflow s SLSA provenance

name: Secure Build with SLSA on: push: branches: [main] jobs: build: runs-on: ubuntu-latest permissions: contents: read id-token: write steps: - uses: actions/checkout@v4 - name: Generate SBOM uses: anchore/sbom-action@v0 with: format: spdx-json output-file: sbom.spdx.json - name: Build and sign container env: COSIGN_EXPERIMENTAL: 1 run: | # Build container s reproducible Dockerfile docker build --build-arg BUILD_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ) \ --build-arg VCS_REF=$GITHUB_SHA \ -t legal-platform:$GITHUB_SHA . # Podepsat s cosign cosign sign --yes legal-platform:$GITHUB_SHA # Připojit SBOM cosign attach sbom --sbom sbom.spdx.json legal-platform:$GITHUB_SHA - name: Generate SLSA provenance uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.9.0 with: image: legal-platform tag: ${{ github.sha }} ```

Běžná úskalí k vyhnutí

- Security theater: implementace kontrol, které neřeší skutečné hrozby; zaměřit se na risk-based kontroly. - Over-engineering: komplexní zero-trust implementace, které rozbíjí user workflows; začít s identitou a daty. - Zanedbávání business continuity: DR testy, které nereflektují skutečné recovery scénáře; testovat plné workflows. - Siloed compliance: správa více frameworků separátně; harmonizovat control sety a evidenci.

Závěr

Odolnost a compliance by design vyžadují systematickou implementaci NIS2 governance, zero-trust architektury, secure SDLC praktik a robustních runtime kontrol. Legal tech platformy, které přijmou tyto praktiky, dosáhnou měřitelné odolnosti při zefektivnění audit procesů a zachování operační efficiency.

Klíčem je zacházení se security a compliance jako s architektonickými rozhodnutími spíše než add-on funkcemi, zajištění jejich embedded přítomnosti napříč technologickým stackem a operačními procesy.