Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Przepływy pracy bezpieczeństwa i zgodności w przedsiębiorstwie

Twój zespół bezpieczeństwa właśnie wstrzymał wdrożenie AI. Pytania są zasadne: gdzie trafia nasz kod źródłowy, czy programista może wkleić dane osobowe klienta do promptu i czy potrafisz udowodnić audytorowi SOC2, kto dokładnie co uruchomił? Ogólnikowe rady w stylu „pisz jasne prompty” nie odpowiadają na żadne z nich. Ten przewodnik pokazuje konkretne, egzekwowalne mechanizmy kontroli, które faktycznie oferuje każde z trzech narzędzi — ustawienia, które przełączasz, konfiguracje, które commitujesz, i skanery, które podpinasz do CI — abyś mógł przejść przegląd i z powrotem włączyć wdrożenie.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Dokładne ustawienie prywatności i retencji danych do wyegzekwowania w Cursor, Claude Code i Codex, tak aby kod źródłowy nie był przechowywany ani używany do treningu.
  • Zacommitowany, egzekwowany maszynowo plik polityki dla każdego narzędzia, który blokuje odczyt .env, niebezpieczne komendy shell i niezatwierdzone serwery MCP — a nie stronę na wiki, którą wszyscy ignorują.
  • Hook PreToolUse i konfigurację pre-commit, które skanują diffy pod kątem sekretów i danych osobowych, zanim cokolwiek opuści maszynę, z użyciem prawdziwego open source (gitleaks, detect-secrets, trivy).
  • Gotowe do wklejenia prompty generujące listę kontrolną przeglądu bramkowaną przez CODEOWNERS, skaner diffów pod kątem sekretów/danych osobowych oraz middleware audytowe SOC2 CC7.1 dla Express + Postgres.
  • Mapowanie kontroli SOC2 / GDPR / HIPAA na powierzchnię audytu, którą udostępnia każde narzędzie (Cursor Admin API, compliance API w Claude for Enterprise, Codex Compliance API).

Krok 1: Wyegzekwuj ochronę danych na poziomie narzędzia

Dział zatytułowany „Krok 1: Wyegzekwuj ochronę danych na poziomie narzędzia”

Te mechanizmy istotnie różnią się między narzędziami, więc skonfiguruj każdy z osobna. Cel jest identyczny: zapobiec przechowywaniu kodu źródłowego i sekretów oraz nie dopuścić, by wrażliwe pliki w ogóle trafiły do kontekstu.

Wyegzekwuj Privacy Mode na poziomie zespołu, aby pojedyncze osoby nie mogły go wyłączyć, a następnie trzymaj wrażliwe pliki poza indeksowaniem i kontekstem za pomocą .cursorignore.

  1. Panel zespołu -> Settings -> włącz Privacy Mode i przełącz Enforce (członkowie nie mogą go już wyłączyć). Privacy Mode jest domyślnie włączony dla Enterprise i daje Ci ZDR ze wszystkimi dostawcami modeli.
  2. Na urządzeniach firmowych wdróż politykę MDM Allowed Team IDs, aby użytkownicy nie mogli zalogować się na konto prywatne, które nie ma Privacy Mode.
  3. Zacommituj .cursorignore, aby sekrety i infrastruktura nigdy nie były indeksowane ani wysyłane jako kontekst:
# .cursorignore — nigdy nie indeksuj ani nie wysyłaj do modeli
.env
.env.*
**/secrets/**
**/*.pem
**/*.key
terraform.tfstate*
**/credentials.json

Dla obciążeń podlegających regulacjom poproś dział sprzedaży o włączenie CMEK (kluczy szyfrowania zarządzanych przez klienta), aby embeddingi i wszelkie dane Cloud Agent były szyfrowane Twoim kluczem. Jeśli Twoja polityka w ogóle zabrania przechowywania kodu, po prostu nie włączaj Cloud Agents — każda inna funkcja Cursora nadal działa.

Krok 2: Zastąp plik z regułami egzekwowaną polityką

Dział zatytułowany „Krok 2: Zastąp plik z regułami egzekwowaną polityką”

Przestarzały jednoplikowy .cursorrules jest wycofywany. Użyj Project Rules w Cursor (.cursor/rules/*.mdc), CLAUDE.md w Claude Code wraz z zacommitowanymi ustawieniami projektu oraz AGENTS.md w Codex. Plik z regułami to wskazówki, których model zazwyczaj przestrzega; to listy deny z Kroku 1 faktycznie je egzekwują. Używaj obu.

Utwórz .cursor/rules/security.mdc. Frontmatter alwaysApply: true wstrzykuje regułę do każdej sesji:

---
description: "Security & data-handling rules"
alwaysApply: true
---


- Never write API keys, passwords, tokens, or connection strings into code. Read them from `process.env`.
- Never put customer PII (names, emails, SSNs, MRNs) in fixtures, logs, or prompts. Use `@faker-js/faker` for test data.
- Mark AI-assisted code with a `// AI-assisted` comment so review and CODEOWNERS can track it.
- Redact secrets before logging; encrypt sensitive data at rest and in transit.

Krok 3: Skanuj diffy pod kątem sekretów i danych osobowych, zanim opuszczą maszynę

Dział zatytułowany „Krok 3: Skanuj diffy pod kątem sekretów i danych osobowych, zanim opuszczą maszynę”

Używaj prawdziwych, utrzymywanych skanerów — a nie ręcznie sklejonej klasy z wyrażeniami regularnymi. gitleaks (binarka Go) i detect-secrets (pip install detect-secrets) wyłapują poświadczenia; trivy wyłapuje podatne zależności i błędną konfigurację. Podepnij je w dwóch miejscach: hook PreToolUse w Claude Code (blokuje commit, który agent ma za chwilę uruchomić) oraz CI (zabezpieczenie końcowe).

Hook to miejsce, w którym te trzy narzędzia się rozchodzą — Claude Code potrafi zablokować wywołanie narzędzia w locie; Cursor i Codex polegają na pre-commit + CI.

Cursor nie ma hooka blokującego commit, więc egzekwuj na warstwie git za pomocą konfiguracji pre-commit, którą dziedziczy każdy klon:

.pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

Uruchom pre-commit install raz na klon (albo wyegzekwuj to przez bootstrap repozytorium). Teraz każdy commit — wspomagany przez AI czy nie — jest skanowany, zanim wyląduje.

Zabezpieczenie w CI jest identyczne niezależnie od tego, które narzędzie napisało kod:

.github/workflows/security-scan.yml
name: Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with: { fetch-depth: 0 }
      - name: Secret scan
        uses: gitleaks/gitleaks-action@v2
      - name: Dependency & misconfig scan
        uses: aquasecurity/trivy-action@v0.36.0
        with: { scan-type: 'fs', severity: 'HIGH,CRITICAL', exit-code: '1' }
      - name: AI-attribution check
        run: |
          count=$(git diff --name-only origin/${{ github.base_ref }}... \
            | xargs grep -l "AI-assisted\|AI-generated" 2>/dev/null | wc -l)
          if [ "$count" -eq 0 ]; then
            echo "::warning::No AI-assisted attribution found in changed files"
          fi

Krok 4: Zmapuj kontrole zgodności na powierzchnię audytu każdego narzędzia

Dział zatytułowany „Krok 4: Zmapuj kontrole zgodności na powierzchnię audytu każdego narzędzia”

Audytorzy nie akceptują „ufamy programistom”. Każde narzędzie udostępnia powierzchnię audytu i dostępu, na którą możesz skierować ocenę SOC2 / GDPR / HIPAA.

  1. SOC2 (CC6 dostęp, CC7.1 wykrywanie). Pobieraj logi dostępu i użycia z powierzchni administracyjnej każdego narzędzia: Admin API Cursora i analityka zespołu, Claude Code przez Claude for Enterprise (SSO, RBAC, compliance API) oraz Compliance API Codeksa, które eksportuje treść promptu, odpowiedzi, użytkownika, znacznik czasu, model i zużycie tokenów wprost do Twojego potoku SIEM/eDiscovery. Dla własnych usług wygeneruj middleware do logowania audytu CC7.1 (prompt poniżej).

  2. GDPR (minimalizacja danych, prawo do usunięcia). Trzymaj dane osobowe całkowicie poza promptami — .cursorignore / permissions.deny / sandbox z Kroku 1 zajmują się tym. W kwestii usuwania, Codex Compliance API oraz eksporty enterprise Cursor/Anthropic pozwalają zlokalizować i rozliczyć każdy rekord powiązany z użytkownikiem. Nigdy nie używaj danych produkcyjnych jako fixtur testowych; zamiast tego generuj dane syntetyczne.

  3. HIPAA (przetwarzanie PHI). Nigdy nie wysyłaj chronionych informacji zdrowotnych do modelu bez podpisanej umowy BAA obejmującej tę konkretną powierzchnię. Domyślnie używaj syntetycznych pacjentów i redaguj PHI, zanim trafi do promptu.

Generuj syntetyczne dane testowe za pomocą utrzymywanego @faker-js/faker (stary samodzielny pakiet faker jest wycofany, a jego API faker.datatype.* już nie istnieje):

import { faker } from '@faker-js/faker';


export function syntheticPatient() {
  return {
    id: faker.string.uuid(),
    name: faker.person.fullName(),
    dob: faker.date.past({ years: 80 }),
    mrn: `TEST-${faker.number.int({ min: 100000, max: 999999 })}`,
    conditions: ['Synthetic Condition A', 'Synthetic Condition B'],
  };
}

Gdy coś przestaje działać

Dział zatytułowany „Gdy coś przestaje działać”
  • Skaner sekretów blokuje każdy commit (fałszywe alarmy). Fixtury testowe o wysokiej entropii i przykładowe klucze wyzwalają gitleaks/detect-secrets. Wygeneruj baseline (detect-secrets scan > .secrets.baseline) i zacommituj go albo dodaj precyzyjny .gitleaksignore — nigdy nie wyłączaj skanowania w całości.
  • Redakcja psuje poprawne prompty. Agresywna redakcja wyrażeniami regularnymi zamienia user@example.com w przykładzie kodu na [REDACTED] i niszczy kontekst agenta. Redaguj na ścieżce diff/commit, a nie w promptcie, który programista aktualnie pisze; lepiej trzymać dane osobowe na zewnątrz (pliki ignore) niż wymazywać je po fakcie.
  • Programista omija politykę. Jeśli ktoś używa konta prywatnego lub --dangerously-skip-permissions, Twoje zacommitowane reguły nic nie robią. Dlatego Krok 1 ma znaczenie: egzekwuj Privacy Mode + Allowed Team IDs (Cursor), disableBypassPermissionsMode + managed settings (Claude Code) oraz RBAC (Codex) na poziomie organizacji, a nie repozytorium.
  • PHI przeciekają, bo „ZDR” wzięto za BAA. Zero Data Retention zapobiega treningowi i przechowywaniu; to nie jest Business Associate Agreement. Brak BAA, brak PHI — i kropka.
  • Serwer MCP, który dodałeś do listy dozwolonych, ma dostęp do systemu plików. Zbyt szeroki serwer MCP może odczytać dokładnie te pliki, które chroni Twoja lista deny. Używaj deniedMcpServers / allowedMcpServers w managed settings Claude Code i sprawdzaj zakres każdego serwera przed zatwierdzeniem.

Co dalej

Dział zatytułowany „Co dalej”

Zobacz co nowego na platformie.

Polityka prywatności Regulamin