# SaferPage Delivery Credential Preflight Delivery-Credential-Preflight: 1 von 7 Zielsystemtypen voll konfiguriert, 0 teilweise, native Runner-Ziele 1, Versandfreigabe nicht aktiv. > Dieser Preflight zeigt nur Credential-Referenzen, Gate-Status und Betriebsnachweise. Er veröffentlicht keine Webhook-URLs, API-Keys, Tokens, E-Mail-Empfänger, Slack-/Teams-Ziel-URLs oder privaten Rohpayloads. ## Alert-Delivery-Readiness-Smoke - Status: passed - Ziele: 7 - Failed Checks: 0 - Erwartete Blocker: 1 - Dry-run gesendet: 0 - Runner gesendet: 0 - Evidence: https://saferpage.de/evidence/alert-delivery-readiness-smoke.json ## Zielsysteme - Lokaler Audit-File-Sink: ready_for_approval, komplett - Generischer Webhook: missing_configuration, fehlt: SAFERPAGE_WEBHOOK_URL, SAFERPAGE_WEBHOOK_SECRET - Slack: missing_configuration, fehlt: SAFERPAGE_SLACK_WEBHOOK_URL - Microsoft Teams: missing_configuration, fehlt: SAFERPAGE_TEAMS_WEBHOOK_URL - Jira: missing_configuration, fehlt: SAFERPAGE_JIRA_BASE_URL, SAFERPAGE_JIRA_EMAIL, SAFERPAGE_JIRA_API_TOKEN - E-Mail/SMTP: missing_configuration, fehlt: SAFERPAGE_MAIL_FROM, SAFERPAGE_MAIL_TO - SendGrid: missing_configuration, fehlt: SENDGRID_API_KEY, SAFERPAGE_MAIL_FROM, SAFERPAGE_MAIL_TO ## Readiness-Gates - Produktive Alert-Zustellung freigegeben: blocked - SAFERPAGE_ALERT_DISPATCH_APPROVED ist nicht aktiv; Runner bleibt Dry-run/Outbox. - Mindestens ein nativ sendbares Zielsystem konfiguriert: passed - 1 native(s) Zielsystem(e) sind voll konfiguriert: Webhook, Slack oder Teams. - HMAC-Signatur für Betreiber-Webhook verfügbar: warning - Kein HMAC-Secret gesetzt; generische Webhooks können nicht signiert werden. - Alert-Dispatch-Runner-State erreichbar: passed - State alert_dispatch_runner_state.json ist lesbar; sent=0, deliverable=0, errors=50. - Dry-run/Outbox als Testnachweis vorhanden: warning - 0 Outbox-Einträge im letzten Runner-State. - No-Secret-Export: passed - Dieser Preflight zeigt nur Env-Referenzen und present/missing-Status, keine Werte, Ziel-URLs, Empfänger, Tokens oder API-Keys. - Runtime-Control-Manifest vorhanden: passed - 8 Delivery-Runtime-Kontrolle(n) im Evidence-Manifest dokumentiert. - Idempotency- und Retry-Vertrag vorhanden: passed - Delivery-Payloads und Runner-State nutzen Idempotency-Key, Body-SHA-256, Status und Stop-Bedingungen. - Zielsystem-Matrix abgedeckt: passed - 1 ready, 0 teilweise, 7 Zielsystemtypen im Preflight. ## Konsolidierungsstand und Grenzen - **Delivery-Verträge vorbereitet** (erreicht): 8 Runtime-Controls, Receiver-Vertrag, Idempotency-Key und Body-SHA-256 sind öffentlich belegbar. Grenze: Das ist ein Integrationsvertrag, keine echte Zustellung an Betreiberzielsysteme. Nächster Schritt: Receiver mit Testziel prüfen: HMAC, Idempotency, Dedupe, Retry und Fehlerantworten dokumentieren. - **Produktive Alert-Zustellung** (blockiert): dispatch_approved=no, runner_sent_count=0, native_ready_channel_count=1. Grenze: Nicht behaupten: Betreiber erhalten produktive Alerts, solange SAFERPAGE_ALERT_DISPATCH_APPROVED nicht aktiv ist. Nächster Schritt: Betreiberfreigabe, Zielsystem, Empfänger, Datenschutz-/Security-Abnahme und Monitoring signieren; erst danach Approval setzen. - **Zielsysteme und Empfänger** (teilweise_erreicht): 1/7 Zielsystemtypen sind voll konfiguriert; 1 sind nativ durch den Runner sendbar. Grenze: Öffentliche Evidence zeigt nur Env-Referenzen und Status; echte Webhook-URLs, Tokens, Channels und Empfänger bleiben privat. Nächster Schritt: Mindestens ein natives Ziel mit Testempfänger einrichten und Zielsystem-Dedupe gegen Idempotency-Key prüfen. - **Dry-run und No-Send-Grenzen** (erreicht): Letzter Smoke: dry_run_sent=0, runner_sent=0, failed_checks=0. Grenze: Smokes und Preflight senden nicht, setzen keine Secrets und prüfen keine privaten Zielsysteme. Nächster Schritt: Nach jeder Zielsystem- oder Runner-Änderung zuerst Dry-run-Smoke, dann Go-live-Center und Alerting-Digest prüfen. - **Wettbewerbs- und Betreiber-Claims** (begrenzt): 6/9 Delivery-Gates passed; 1 Blocker und 2 Warnungen bleiben sichtbar. Grenze: Nicht behaupten: automatische Alerts, Support-Ziel-Eskalation oder Nachweispositions-Zustellung sind live, solange Zielsystem- und Approval-Gates offen sind. Nächster Schritt: Vergleichs- und Betreibertexte nur mit Claim-Grenzen ausgeben; blockierte Gates im Go-live-Board offen lassen. ## Claim-Grenzen - **Keine produktiven Alerts behaupten** Erlaubt: Alert-Delivery ist vorbereitet, no-secret dokumentiert und als Dry-run prüfbar. Nicht behaupten: Betreiber erhalten produktive Alerts. Grund: Produktiver Versand braucht Zielsystem, Empfängerfreigabe, SAFERPAGE_ALERT_DISPATCH_APPROVED=yes, Receiver-Abnahme und Nachlaufkontrolle. - **Keine Empfänger oder Webhook-URLs veröffentlichen** Erlaubt: Public Exports zeigen Env-Referenzen, Status, Hashes und Idempotency-Keys. Nicht behaupten: Webhook-URLs, Slack-/Teams-Ziele, E-Mail-Empfänger, Tokens oder API-Keys sind öffentliche Evidence. Grund: Zielsystemdaten sind Secrets bzw. personenbezogene oder sicherheitsrelevante Betriebsdaten. - **Dry-run ist kein Versand** Erlaubt: Dry-run belegt Payload, Routing, No-Secret-Regeln und Stop-Bedingungen. Nicht behaupten: Dry-run beweist erfolgreiche Zustellung im Betreiberkanal. Grund: Dry-run darf keine externen Sends, keine produktiven Sinks und keine privaten Zielsysteme auslösen. - **Receiver-Abnahme vor Go-live** Erlaubt: Receiver-Vertrag nennt HMAC, Idempotency, Body-Hash, Retry und Stop-Bedingungen. Nicht behaupten: Jedes Zielsystem ist automatisch kompatibel. Grund: Zielsysteme müssen Signatur, Dedupe, Fehlercodes und Rate-Limits selbst validieren. - **Keine Support-Ziel-/Eskalationsclaims ohne Nachlauf** Erlaubt: Alerting-Digest beschreibt Support-Ziele, Eskalations- und Incident-Drill-Blueprints. Nicht behaupten: Support-Ziel-Eskalation ist produktiv garantiert. Grund: Support-Ziel-Claims brauchen echten Versand, Monitoring, Fehlerbudget, Pausenpolicy und Betreiber-Nachlauf. ## Run-Policy - Externe Zustellung nur wenn: --execute-ready was passed, SAFERPAGE_ALERT_DISPATCH_APPROVED=yes and the channel target is configured - External Attempts: 0 - Local File-Sink Attempts: 0 - No-Secret-Export: ja ## Credential-Referenzen - SAFERPAGE_ALERT_DISPATCH_APPROVED: missing - Explicit approval gate for productive alert delivery. - SAFERPAGE_WEBHOOK_URL: missing - Generic operator webhook target. - SAFERPAGE_WEBHOOK_SECRET: missing - HMAC-SHA256 signing secret for generic webhook deliveries. - SAFERPAGE_SLACK_WEBHOOK_URL: missing - Slack incoming webhook target. - SAFERPAGE_TEAMS_WEBHOOK_URL: missing - Microsoft Teams incoming webhook target. - SAFERPAGE_LOCAL_FILE_SINK_PATH: missing - Optional override for sanitized local JSONL audit sink; default path is used when absent. ## Delivery-Verantwortungs-Handoff - Status: waiting_for_receiver_target_and_operator_approval - Zusammenfassung: Delivery-Handoff für Betreiber, Receiver-Verantwortung und Security: Zielsysteme, Empfänger, Approval, HMAC, Dry-run und Claims werden no-secret getrennt. ### Übergabeschritte - **Receiver-Scope festlegen** (Betreiber/IT): Kanal, Eventtypen, Testempfänger, Zweck und Eskalationsfenster privat festlegen. Abnahme: Scope nennt Zielsystemtyp, Rollenempfänger, Eventtypen, Testfenster und Rollback-Verantwortlichkeit. Grenze: Öffentlich erscheinen Rollen und Status, keine echten Empfänger oder Ziel-URLs. Evidence: https://saferpage.de/integrationen/delivery-credential-preflight-json - **Zielsystem-Referenzen privat setzen** (Platform/Security): Webhook-, Slack-, Teams-, Jira-, SMTP- oder SendGrid-Refs nur in sicherer Server-Env oder Secret Manager setzen. Abnahme: Preflight zeigt present/missing-Status; Public Exports enthalten keine Zielwerte. Grenze: Env-Template bleibt Placeholder; echte Werte dürfen nie committed oder publiziert werden. Evidence: https://saferpage.de/integrationen/delivery-approval-template.env - **Receiver-Vertrag abnehmen** (Receiver-Verantwortung): HMAC, Idempotency-Key, Body-SHA-256, Retry, Fehlercodes und Dedupe im Testreceiver prüfen. Abnahme: Receiver akzeptiert signierte Testpayloads, dedupliziert Wiederholungen und liefert definierte Fehlerantworten. Grenze: Payload-Fixture beweist Vertrag, aber keine erfolgreiche Produktivzustellung. Evidence: https://saferpage.de/alarme/anrufer.info/delivery-json - **No-Send-Dry-run ausführen** (Security/Platform): Alert-Dispatch-Dry-run und Readiness-Smoke ausführen, bevor Approval gesetzt wird. Abnahme: sent_count=0, external_send_attempt_count=0, failed_check_count=0; erwartete Blocker bleiben sichtbar. Grenze: Dry-run ist keine Zustellung an Betreiberkanal. Evidence: https://saferpage.de/evidence/alert-delivery-readiness-smoke.json - **Dispatch-Gate signieren** (Betreiber/Security): SAFERPAGE_ALERT_DISPATCH_APPROVED erst nach Receiver-, Empfänger-, Datenschutz- und Stop-Bedingungsfreigabe aktivieren. Abnahme: Approval-Record nennt Scope, Testrefs, Smoke-Refs, Rollback-Verantwortlichkeit und Review-Ablauf. Grenze: Freigabestatus darf öffentlich sein; Personen, Empfänger und interne Nachweis-URLs bleiben privat. Evidence: https://saferpage.de/betreiber/go-live-json - **Receiver-Canary kontrolliert starten** (Platform/Receiver-Verantwortung): Ersten produktionsnahen Test mit begrenztem Scope ausführen und Runner-State, Zielsystem-Dedupe und Fehlerquote prüfen. Abnahme: sent_count steigt nur für freigegebenen Scope; error_count=0; Dedupe und Pausepfad sind belegt. Grenze: Canary ist begrenzter Test, kein pauschales Support-Ziel- oder Alert-Versprechen. Evidence: https://saferpage.de/alarme/dispatch-runner-json ### Private Inputs - **Webhook-/Slack-/Teams-/Jira-Ziel-URL**: Produktive Zustellung braucht ein konkretes Betreiberziel. Public Handling: Nie öffentlich ausgeben; nur Zielsystemtyp und present/missing zeigen. - **HMAC-/Webhook-Secret**: Receiver muss Payloads authentifizieren können. Public Handling: Nur Signaturalgorithmus und Headernamen zeigen. - **Empfänger-/Channel-Freigabe**: Alerts können personenbezogene oder betriebsinterne Informationen betreffen. Public Handling: Nur Rollen, Zweck und Freigabestatus zeigen. - **Dispatch-Approval-Record**: Produktiver Versand braucht dokumentierten Go-live-Entscheid. Public Handling: Nur Status, Scope-Klasse, Evidence-Refs und Reviewdatum öffentlich. - **Privates Receiver-Testlog**: Zielsystem muss Dedupe, Fehlercodes und Retry belegen. Public Handling: Nur aggregierte Abnahme und Hash-/Request-ID-Referenzen zeigen. - **Rollback-/Pause-Verantwortlichkeit**: Falsche oder doppelte Zustellungen müssen sofort pausierbar sein. Public Handling: Nur Rolle und Stop-Bedingungen öffentlich zeigen. ### Öffentlich erlaubte Outputs - **Env-Referenzstatus**: Preflight kann ready/missing zeigen, ohne Werte offenzulegen. - **Receiver-Vertrag**: HMAC, Idempotency und Body-SHA-256 sind prüfbare Integrationsanforderungen. - **Dry-run-Zähler**: No-Send-Guardrails sind messbar. - **Runner-Statuszähler**: sent/error/outbox zeigen Betriebszustand ohne Zielsystemdetails. - **Stop-Bedingungen**: Betreiber sehen, wann Versand pausiert werden muss. - **Approval-Status**: Go-live-Gate ist nachvollziehbar, ohne Empfänger zu nennen. - **SaferPage-Evidence-URLs**: Abnahme bleibt verlinkbar und maschinenlesbar. ### Verbotene Outputs - Webhook-, Slack-, Teams-, Jira-, SMTP- oder SendGrid-Ziel-URLs - API-Keys, Tokens, HMAC-Secrets, SMTP-Passwörter oder Authorization-Header - E-Mail-Adressen, Slack-Channels, Teams-Channel-IDs oder echte Empfängerlisten - Private Alert-Payloads, Rohpayloads, Kundendokumente oder interne Nachweispositionstexte - Zielsystem-Testlogs mit Personen, Hostnamen, internen URLs oder Request-Body - Secret-Manager-Pfade, Environment-Dateien mit echten Werten oder Shell-History - Betreiberentscheidung mit Personennamen, privaten Nachweis-URLs oder internen Kommentaren - Behauptung erfolgreicher Produktivzustellung ohne Approval, Receiver-Abnahme und Runner-Evidence ### Validierungschecks - Delivery-Preflight zeigt blocked_gate_count > 0, solange Zielsystem oder Approval fehlt. - Alert-Delivery-Smoke zeigt dry_run_sent_count=0 und runner_sent_count=0 vor Approval. - Public Exports enthalten keine Webhook-/Slack-/Teams-URLs, Tokens, API-Keys oder Empfänger. - Receiver-Fixture enthält Idempotency-Key, Body-SHA-256 und HMAC-Vertrag. - Go-live-Center verlinkt Delivery-Phase, Rollback und Nachlaufbeobachtung. ### Handoff-Abnahme - Mindestens ein natives Zielsystem ist privat konfiguriert oder bewusst blockiert dokumentiert. - Receiver prüft Idempotency-Key und optional HMAC-Signatur. - Dry-run-Smoke bleibt ohne externe Sendung grün. - Dispatch-Approval ist erst nach Zielsystem-, Empfänger-, Datenschutz- und Security-Freigabe aktiv. - Public Evidence enthält keine Ziel-URLs, Tokens, Empfänger, Secrets oder Rohpayloads. - Runner-State nach Canary zeigt begrenzten Scope, keine Fehler und nachvollziehbare Dedupe-Referenz. - Produktclaims bleiben auf vorbereitet/no-secret belegbar begrenzt, bis echte Zustellung belegt ist. ### Delivery-Signoff-Receipt - Status: blocked_until_target_and_approval - Zusammenfassung: Maschinenlesbares Betreiber-Receipt für Delivery-Go-live: private Zielsystemdaten bleiben privat; öffentlich werden nur Status, Evidence-Refs, Hash-/Dedupe-Referenzen und Stop-Bedingungen. - Private Inputs: 7 - Public Fields: 8 - Evidence URLs: 7 - Verification Checks: 6 - No-Secret-Attestations: 6 - Public Export Policy: Nur Receipt-ID, Scope-Klasse, Status, Evidence-URLs, Hash-/Dedupe-Referenzen und aggregierte Zähler sind öffentlich; private Inputs bleiben im Betreiber-System. ## Aktivierungssequenz - Zielsystem-Verantwortlichkeit, Empfänger, Kanaele und Zwecke festlegen. - Secrets und Ziel-URLs in /etc/saferpage/alert-dispatch.env oder Secret Manager setzen. - Ohne SAFERPAGE_ALERT_DISPATCH_APPROVED einen Dry-run ausführen und /alarme/dispatch-runner-json prüfen. - HMAC-Signatur, Idempotency-Key, Body-SHA-256 und Zielsystem-Dedupe im Testempfänger verifizieren. - SAFERPAGE_ALERT_DISPATCH_APPROVED=yes erst nach dokumentierter Betreiberfreigabe setzen. - Nach erstem produktiven Lauf sent_count, error_count und Zielsystem-Logs prüfen. ## Stop-Bedingungen - sent_count größer 0 ohne SAFERPAGE_ALERT_DISPATCH_APPROVED=yes und dokumentierte Betreiberfreigabe. - Öffentliche Exports enthalten Ziel-URLs, API-Keys, Tokens, E-Mail-Empfänger, Slack-/Teams-Webhook-URLs oder private Payloads. - Zielsystem meldet Duplikate trotz Idempotency-Key. - error_count größer 0 oder wiederholte HTTP-/TLS-/Rate-Limit-Fehler. - Empfänger oder Kanalzweck wurden ohne Datenschutz-/Security-Abnahme geändert. ## Delivery-Approval-Paket - Env-Datei: /etc/saferpage/alert-dispatch.env - Template: https://saferpage.de/integrationen/delivery-approval-template.env - Sendet selbst: nein ### Env-Referenzen - SAFERPAGE_ALERT_DISPATCH_APPROVED: Finales Betreiber-Go-live-Gate; erst nach Dry-run, Empfänger- und Datenschutzfreigabe auf yes setzen. - SAFERPAGE_WEBHOOK_URL: Generisches Betreiber-Webhook-Ziel. - SAFERPAGE_WEBHOOK_SECRET: HMAC-SHA256-Secret für generische Webhook-Payloads. - SAFERPAGE_SLACK_WEBHOOK_URL: Slack Incoming Webhook für PrivacyOps-/Security-Alerts. - SAFERPAGE_TEAMS_WEBHOOK_URL: Microsoft Teams Incoming Webhook für Betreiber-Alerts. - SAFERPAGE_LOCAL_FILE_SINK_PATH: Optionaler lokaler Audit-Sink für sanitisierte Zustellnachweise. ### Smoke-Matrix - `scripts/run-alert-dispatch-dry-run-smoke.sh`: sent_count=0, external_send_attempt_count=0, local_file_sink_attempt_count=0. - `python3 scripts/run-alert-dispatch.py anrufer.info --base-url http://127.0.0.1 --max 1 --timeout 15 --execute-ready`: Ohne SAFERPAGE_ALERT_DISPATCH_APPROVED=yes bleibt sent_count=0. - `curl -fsS https://saferpage.de/alarme/anrufer.info/delivery-json`: Payload enthält Idempotency-Key, body_sha256 und HMAC-Receiver-Vertrag ohne Ziel-URL. - `curl -fsS https://saferpage.de/alarme/dispatch-runner-json`: Public State enthält nur Env-Refs, Hashes und Status; keine Secrets, Ziel-URLs oder Empfänger. ### Abnahme - [ ] Mindestens ein externes natives Zielsystem ist serverseitig konfiguriert oder der lokale File-Sink ist für Audit-Dry-run bewusst als einziges Ziel zugelassen. - [ ] SAFERPAGE_ALERT_DISPATCH_APPROVED=yes ist erst nach dokumentierter Betreiberfreigabe gesetzt. - [ ] Receiver prüft X-SaferPage-Idempotency-Key und optional X-SaferPage-Signature. - [ ] Dry-run-Smoke zeigt keine externen Sendungen und keine Secret-Leaks. - [ ] Nach erstem produktiven Lauf sind sent_count, error_count und Zielsystem-Dedupe dokumentiert.