sendnrw/prom-ping
2
0
Fork 0
generated from sendnrw/template_golang
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
prom-ping/SECURITY.md
sendnrw 4b63943a6f Initial commit
2025-10-31 05:43:30 +00:00

8.5 KiB
Raw Permalink Blame History

SECURITY.md

Inhalt

Kontakt & Meldung von Schwachstellen

Wenn Sie eine Schwachstelle gefunden haben, melden Sie diese vertraulich:

  • E-Mail: security@patchping.org
  • Optional PGP: , öffentlicher Schlüssel: <Link/Key-ID>
  • Reaktionsziel: Erstbestätigung innerhalb von 3 Werktagen, Status-Update innerhalb von 7 Tagen.
  • Bitte nutzen Sie Responsible Disclosure: Keine öffentliche Offenlegung, keine Datenveränderung, keine Dienstunterbrechung. Testen Sie nur Systeme im Geltungsbereich.

Außerhalb des Geltungsbereichs: Social Engineering, physischer Zugriff, DDoS/Stress-Tests ohne ausdrückliche schriftliche Genehmigung.

Geltungsbereich

  • Repos / Services: <repo-name>, <service-name>
  • Umgebungen: Dev, Staging, Production
  • Abhängigkeiten: Alle in package.json/go.mod/requirements.txt etc.
  • Nicht umfasst: Drittanbieter-Dienste außerhalb unserer Kontrolle, persönliche Forks.

Unterstützte Versionen

Version Status Sicherheitsfixes bis
main aktiv laufend
vX.Y LTS (12 Mon.) <Datum>
<älter> EOL –

Sicherheitsupdates erhalten ausschließlich unterstützte Linien.

Transport & Netzwerksicherheit (TLS)

  • Anforderung: TLS 1.2+ (bevorzugt TLS 1.3).
  • Zertifikate: Aus vertrauenswürdigem CA-Store, OCSP-Stapling aktivieren, HSTS mit Preload für Public Sites (nach sorgfältiger Prüfung).
  • Cipher: Moderne Profile (z. B. Mozilla „intermediate“ oder „modern“). Kein TLS_RSA_*, keine Null-/Export-Cipher.
  • Perfect Forward Secrecy (ECDHE) verpflichtend.
  • In-Cluster (Service-zu-Service): mTLS (z. B. mit Service Mesh oder Sidecars).

Beispiel NGINX (vereinfacht):

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5:!3DES;
ssl_session_cache shared:SSL:10m;
ssl_stapling on; ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Secret-Management (Docker-Secrets, Vault, .env)

  • Do not: Secrets in Git, Images, Layern oder in ENV persistieren.
  • Do:
    • Docker Swarm/Kubernetes/Compose Secrets oder Vault / Cloud Secret Manager verwenden.
    • Rotations-Policy, minimale TTLs, Least Privilege.
    • Im Code nur über Files/Runtime einlesen (/run/secrets/... o. ä.).

Docker Compose (Beispiel):

services:
  app:
    image: your/app:latest
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
  db_password:
    file: ./secrets/db_password.txt  # nicht ins Repo committen

Im Code (Pseudocode):

import os, pathlib
def read_secret(path_or_envfile):
    p = os.getenv("DB_PASSWORD_FILE", path_or_envfile)
    return pathlib.Path(p).read_text(encoding="utf-8").strip()

Für lokale Entwicklung: .env.example bereitstellen, .env in .gitignore.

Container & Orchestrierungs-Sicherheit

  • Images: Minimal-Basis (distroless/alpine), keine Paketmanager/Compiler in Runtime-Images; immutable Tags + Digests pinnen.
  • User: Container nicht als root (USER 10001:10001).
  • FS: readOnlyRootFilesystem, nur benötigte Volumes.
  • Capabilities: Drop all; selektiv erlauben (NET_BIND_SERVICE etc.).
  • Seccomp/AppArmor: Restriktive Profile aktivieren.
  • Netzwerk: Default-Deny zwischen Pods/Services, nur benötigte Egress/DNS.
  • Runtime: Health/Readiness, Ressourcengrenzen (requests/limits), Image-Signing (z. B. cosign).

Dockerfile (Skizze):

FROM gcr.io/distroless/python3
WORKDIR /app
COPY app/ /app
USER 10001:10001
CMD ["python", "main.py"]

Sicheres Hosting & Infrastruktur-Hardening

  • Zugriff: MFA/2FA überall, FIDO2 bevorzugt; keine Passwort-SSH-Logins, nur Keys; kurzlebige Zugangstokens (OIDC).
  • Patchen: OS & Middleware regelmäßig, automatische Sicherheitsupdates wo möglich.
  • Firewalls/WAF: Eingehend/ausgehend minimal; Rate Limiting.
  • Logs: Zentral sammeln (tamper-evident), Zeit/NTP synchronisieren.
  • Backups: Verschlüsselt (at rest & in transit), Restore-Tests (mind. quartalsweise).
  • DNS/Email: DNSSEC wo möglich; SPF, DKIM, DMARC „quarantine/reject“.
  • Cloud: Least Privilege IAM, getrennte Accounts/Projekte pro Umgebung, Security Groups knauserig.

Supply-Chain, Abhängigkeiten & SBOM

  • Pinning: Exakte Versionen (oder Range + Lockfiles).
  • Automatische Updates: Renovate/Dependabot mit Review.
  • Scanning: SCA (Dependencies), Image-Scanner (Trivy/Grype), OS-Patches.
  • SBOM: Erzeugen (CycloneDX oder SPDX) und dem Release beilegen.
  • Verifikation: Signierte Artefakte (Sigstore/cosign); Registry-Policies (nur signiert zulassen).

CI/CD & Releasemanagement-Sicherheit

  • Branch Protection: Reviews, status checks, signierte Commits/Tags.
  • Secrets im CI: Nur benötigte Variablen, maskiert; keine Secrets in Job-Logs; OIDC-Föderation statt dauerhafter Cloud-Keys.
  • Isolierung: Untrusted PRs in isolierten Workflows ohne Secrets; Dependency Caching mit Prüfsummen.
  • Artefakte: Prüfsummen/Signaturen veröffentlichen; Provenance (SLSA-Gedanken).
  • Checks: SAST, IaC-Scan (Terraform/K8s), Container-Scan als Pflicht vor Release.

Anwendungs-Hardening (Headers, CORS, CSP)

  • Security Headers (Beispiele):
    • Content-Security-Policy: default-src 'self' (feinjustieren)
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY (oder SAMEORIGIN falls nötig)
    • Referrer-Policy: no-referrer
    • Permissions-Policy: camera=(), geolocation=()
  • CORS: Nur notwendige Origins/Methoden/Headers; keine * für Credentials.
  • AuthN/Z: Rate Limits, Lockouts, MFA-Optionen; sichere Session-Cookies (Secure, HttpOnly, SameSite=Strict).
  • Crypto: Bewährte Bibliotheken, aktuelle Algorithmen, kein Eigenbau.

Daten & Protokollierungsrichtlinien

  • Klassifizierung: Öffentliche / Intern / Vertraulich / Geheim.
  • PII: Data Minimization; Verschlüsselung at rest (z. B. AES-256), Feld-Level-Encryption bei Bedarf.
  • Logs: Keine Secrets/PII; Rotations- & Aufbewahrungsfristen; Zugriff nur für Befugte.
  • DSGVO: Rechtsgrundlage dokumentieren, Betroffenenrechte, Auftragsverarbeiterverträge.

Sicherheits-Tests

  • SAST: Bei jedem Commit/PR.
  • DAST: Gegen Staging mit Test-Accounts.
  • IaC/Cloud: Terraform/K8s/Cloud Config Scanner.
  • Dependency/Container: bei jedem Build.
  • Penetrationstests/Bug Bounty: Mind. jährlich bzw. vor großen Releases; Scope wie oben.

Vorfallreaktion & Backups

  • Runbooks: Erkennung → Eindämmung → Beseitigung → Wiederherstellung → Lessons Learned.
  • Kommunikation: Interne Kanäle, Eskalationsmatrix, rechtliche Meldepflichten (z. B. 72-Stunden-Fenster beachten).
  • Backups: 3-2-1-Regel, regelmäßige Restore-Drills, KMS-geschützt.

Bedrohungsmodell (kurz)

  • Angriffsflächen: Öffentliche HTTP(S)-Endpunkte, CI/CD, Artefakt-Registry, Admin-Backends, Supply-Chain.
  • Gegner: Opportunistische Angreifer, Botnets, gezielte Kompromittierung von Zugangsdaten.
  • Kontrollen (Auszug): MFA, mTLS, Least Privilege, Code-& Dependency-Scans, signierte Builds, Netzwerk-Policies, Monitoring/Alerting.

Änderungshistorie

  • 30.01.2025 – Initiale Version.
Reference in New Issue View Git Blame Copy Permalink