> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # STIR/SHAKEN-Attestierungslage > Setzen Sie Ihr Outbound-Attestierungsziel und die Downgrade-Behandlung, pruefen Sie delegierte Zertifikate (BYON) und lesen Sie die Lage pro Nummer sowie die eingehende Verifizierung Ihres Sprachverkehrs. # STIR/SHAKEN-Attestierungslage STIR/SHAKEN fuegt jedem ausgehenden Anruf eine kryptografische Signatur hinzu, die auf einer von drei Attestierungsebenen bewertet wird: **A** (voll — der Traeger kennt Sie und Ihr Recht zur Nutzung der anrufenden Nummer), **B** (teilweise — der Traeger kennt Sie, aber nicht die Berechtigung jeder Nummer) oder **C** (Gateway — Ursprung unverifiziert). Empfaenger nutzen diese Ebene, um das Robocall-Risiko abzuwaegen, sodass Ihre Lage die Annahmeraten direkt beeinflusst. Steuern Sie Ihre Attestierungslage ueber **Einstellungen → Compliance → Attestierung**: Deklarieren Sie die Ebene, die Sie fuer ausgehende Anrufe anstreben, legen Sie fest, wie unter dem Ziel liegende Downgrades gemeldet werden, registrieren Sie delegierte Zertifikate, die verifizierte externe Nummern (BYON) von Gateway (C) auf teilweise (B) anheben, und lesen Sie eine Live-Lagemomentaufnahme jeder Ursprungsnummer sowie der eingehenden Verifizierung. Diese Seite beschreibt die eigenen Attestierungssteuerungen Ihres Tenants. Sie ist **keine Rechtsberatung**, und Orbit schreibt Ihnen weder eine Zielebene vor noch garantiert eine bestimmte STIR-Attestierung — der massgebliche Traeger signiert den ausgehenden Verkehr und wird nicht hoeher signieren, als die Plattform attestiert. Die Richtlinie und die Status, die Sie hier setzen, steuern das Reporting; sie sperren oder routen einen Anruf niemals um. *** ## 1. Steuerungsumfang Ihre Attestierungsrichtlinie ist ein Singleton aus vier tenant-eigenen Optionen: | Steuerung | Werte | Was sie regelt | | ---------------------------------------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Outbound-Attestierungsziel** | `A` (voll), `B` (teilweise), `C` (Gateway) | Die SHAKEN-Ebene, die Sie anstreben. Lagevergleiche kennzeichnen jede Ursprungsnummer, die darunter attestiert. | | **Downgrade-Behandlung** | `monitor` (still erfassen, Standard) oder `alert` | Wie unter dem Ziel liegende Anrufe im Reporting behandelt werden. Reine Beobachtbarkeitspraeferenz — sie blockiert oder routet einen Anruf nie um. | | **Eingehende Verifizierungsuntergrenze** | `any`, `A`, `B` oder `C` | Die eingehende Identity-Header-Ebene, die Sie fuer die Betrugslage als verifiziert behandeln. `any` akzeptiert eine gueltige Signatur auf jeder Ebene; eine Buchstaben-Untergrenze erfordert mindestens diese Ebene. | | **Spoofing-Risiko-Kennzeichnung** | Ein / Aus | Ob unsignierte oder an der Validierung gescheiterte eingehende Anrufe in Ihrer Lagemomentaufnahme als Spoofing-Risiko zaehlen. Nur Reporting — ein eingehender Anruf wird nie blockiert. | Auf derselben Seite gibt es drei Steuerungsebenen: das **Richtlinienformular** (diese vier Optionen), den Abschnitt **Delegierte Zertifikate** (BYON-Upgrades) und die **Lagemomentaufnahme** (schreibgeschuetzte Messung). Alle drei Endpunkte liegen unter `/compliance/attestation` und erfordern eine authentifizierte Sitzung. *** ## 2. Ziel und Downgrade-Behandlung setzen Nur Workspace-**Inhaber und Administratoren** koennen die Richtlinie schreiben. 1. Oeffnen Sie **Einstellungen → Compliance → Attestierung**. 2. Waehlen Sie unter **Attestierungsrichtlinie** Ihre Zielebene. Denken Sie an die Gewichtung: Nummern, die Sie besitzen, attestieren A, geleaste Pool-Nummern attestieren B, und alles andere attestiert C. 3. Waehlen Sie einen Downgrade-Modus — die meisten Tenants lassen **Monitor** aktiviert und wechseln zu **Alert**, waehrend sie aktiv eine Luecke bearbeiten. 4. Setzen Sie die eingehende Verifizierungsuntergrenze und die Spoofing-Risiko-Kennzeichnung. 5. Waehlen Sie **Richtlinie speichern**. Dieselbe Richtlinie ist ueber die API lesbar und schreibbar: * `GET /compliance/attestation/policy` gibt die Richtlinie zurueck (mit sicheren Standardwerten fuer einen Tenant, der nie eine gesetzt hat). * `PUT /compliance/attestation/policy` akzeptiert einen partiellen Patch; fehlende Felder behalten ihren aktuellen Wert. Unter dem Ziel liegende Downgrades bleiben eine Reporting-Semantik: Das Setzen von `alert` kennzeichnet Anrufe, die unter Ihrem Ziel attestieren, damit Ihr Team sie pruefen kann — der Anruf wird dennoch durchgelassen. *** ## 3. Delegierte Zertifikate pruefen (BYON / verifizierte Anrufer-ID) Die ausgehenden Ebenen leiten sich aus dem Nummernbesitz ab: Eine eigene Nummer ist A, eine aktive Pool-Lease ist B, und alles andere — einschliesslich einer verifizierten externen oder gehosteten Nummer, die Sie legitim kontrollieren, aber in Orbit nicht besitzen (BYON) — ist Gateway (C). Nachgelagerte Traeger versehen C-bewertete Anrufe haeufig mit einem Spam-Vermerk, was die Annahmeraten senkt. Die Registrierung eines ATIS-1000092-**Delegat-Zertifikats** hebt die von ihm abgedeckten Nummern von C auf B an. Ein Delegat-Zertifikat kann immer nur **teilweise (B) erreichen, niemals voll (A)**: Die Kette ist tenant-seitig geliefert und ihre verzeichnete Abdeckungsliste ist freie Eingabe, daher kann die Plattform keine vollstaendige Attestierung zusichern — und ein selbstregistriertes Zertifikat darf das nie vortaeuschen. Das Register liegt unter `/compliance/attestation/delegate-certs` mit einem vollstaendigen Lebenszyklus: **Registrieren** (`POST`), **Auflisten** (`GET`), **Widerrufen** (`DELETE`). Der Abschnitt im Dashboard auf derselben Seite ruft es fuer Sie auf. ### Zertifikat registrieren 1. Beschaffen Sie die Delegat-Zertifikatskette (PEM) von Ihrem Dienstanbieter, gemaess ATIS-1000092. 2. Waehlen Sie **Zertifikat registrieren**. 3. Fuegen Sie die Zertifikatskette ein, listen Sie die **abgedeckten Nummern** in E.164 (durch Komma oder Zeilenumbruch getrennt) auf und setzen Sie das Fenster **gueltig ab** / **gueltig bis**. Sie koennen das Zertifikat benennen und dessen **Service Provider Code (SPC)** erfassen — beides ist optional. Ein Zertifikat kann einzelne Nummern, inklusive Nummernbereiche oder beides abdecken. 4. **Registrieren.** Die Abdeckung beginnt mit dem Zeitstempel **gueltig ab** des Zertifikats. ### Tabelle lesen Jedes registrierte Zertifikat zeigt seinen Namen, die Abdeckung (die Nummern und Bereiche, die es autorisiert), seinen **effektiven Status** und das Gueltig-bis-Datum. Der effektive Status wird live abgeleitet, sodass Sie den richtlinienrelevanten Zustand sehen, nicht nur das, was dem Register zuletzt mitgeteilt wurde: * **Aktiv** — jetzt gueltig; abgedeckte Nummern attestieren B. * **Ausstehend** — registriert, aber der Zeitpunkt **gueltig ab** liegt noch in der Zukunft. * **Abgelaufen** — nach **gueltig bis**; die Abdeckung gilt nicht mehr und Nummern fallen auf ihre besitzbasierte Ebene zurueck. * **Widerrufen** — Sie haben es widerrufen; derselbe Rueckfall wie bei abgelaufen. ### Widerrufen Waehlen Sie bei einem Zertifikat die Aktion zum Loeschen und bestaetigen Sie. Der Widerruf beendet das B-Attestieren abgedeckter Nummern **sofort** — sie fallen auf ihre besitzbasierte Ebene zurueck — und kann nicht rueckgaengig gemacht werden. Der Datensatz wird mit einer Widerrufen-von-Zeile zum Auditieren aufbewahrt; Widerrufen loescht die Historie nicht. *** ## 4. Verkehrslage lesen Die Karte **Attestierungslage** auf derselben Seite (`GET /compliance/attestation/posture`) misst Ihren aktuellen Zustand gegen Ihre Richtlinie. ### Ursprungsnummern Eine Summenzeile zeigt, wie viele Ursprungsnummern Sie haben, wie viele Ihr Ziel erreichen, wie viele darunter liegen und die Aufschluesselung pro Ebene (A / B / C). Darunter listet eine Tabelle pro Nummer jede Nummer, ihre **Quelle** (`owned` oder `leased`), die auf sie angewendete Attestierungsebene und ob sie Ihr Ziel erreicht — sodass Sie den konkret zurueckgehaltenen Identifikator erkennen, statt nur ein Aggregat zu lesen. ### Eingehende Verifizierung Eine eingehende Zusammenfassung der letzten 30 Tage zaehlt **eingehende Anrufe gesamt**, **verifiziert**, **unverifiziert**, **Spoofing-Risiko** und die **Verifizierungsrate**, wobei „verifiziert“ bedeutet, dass der eingehende Identity-Header die Verifizierungsuntergrenze erfuellt, die Sie in der Richtlinie gesetzt haben. Ein Anruf zaehlt als Spoofing-Risiko, wenn er unsigniert ist oder die SHAKEN-Validierung scheitert und Ihre Spoofing-Risiko-Kennzeichnung aktiviert ist. ### Wie Ebenen die Gateway-Behandlung beeinflussen Attestierungsebenen reisen mit dem Anruf, damit empfangende Traeger das Risiko abwaegen koennen: A ist das staerkste Signal, B wird von den meisten Empfaengern akzeptiert und C ist das schwaechste und am ehesten als zweifelhaft Behandelte. Weil Downgrade- und Spoofing-Risiko-Behandlung hier reines Reporting sind, bedeutet „unter dem Ziel“ oder „unverifiziert“ niemals blockiert — es bedeutet zur Pruefung fuer Sie gekennzeichnet. *** ## 5. Typische Reaktionsereignisse **Teilweises Upgrade auf BYON-Nummern.** Ihr ausgehender Verkehr stammt von einer verifizierten externen oder gehosteten Anrufer-ID, die Ihr Team kontrolliert, aber in Orbit nicht besitzt, sodass diese Anrufe C attestieren und als unter dem Ziel gekennzeichnet werden. Registrieren Sie ein Delegat-Zertifikat, das diese Nummern abdeckt; sie wechseln zu B und werden in der Tabelle pro Nummer als ein C- oder B-Ziel erfuellend gelesen. **Zertifikat naehert sich dem Ablauf.** Beobachten Sie die Spalte **gueltig bis** und registrieren Sie mit einer erneuerten Kette erneut, bevor das Fenster schliesst. Sobald es auf **Abgelaufen** wechselt, fallen abgedeckte Nummern auf ihre besitzbasierte Ebene zurueck, was die Luecke unter dem Ziel wieder oeffnet. **Unrealistisches Ziel.** Wenn Sie Ziel A setzen, waehrend Sie von geleasten Pool-Nummern (B) oder unabgedeckten BYON-Nummern (C) ausgehen, leuchtet der Zaehler unter dem Ziel auf — entweder decken Sie diese Nummern mit einem Delegat-Zertifikat ab (sofern BYON und Sie die Kette besitzen) oder akzeptieren ein B-Ziel, bis sich die Abdeckung aendert. **Eingehender Spoofing-Risiko-Anstieg.** Wenn die eingehende Zusammenfassung einen verdaechtigen Verifizierungsratenabfall oder einen Anstieg im Spoofing-Risiko zeigt, pruefen Sie den Verkehr, bevor Sie Ihre Untergrenze nachjustieren. Das Verschaerfen der Untergrenze auf `A only` klassifiziert jeden eingehenden B- und C-Anruf als unverifiziert neu — behandeln Sie das als Verschiebung der Pruefungsunterstuetzung, nicht als Blockierungsregel. *** ## 6. Tenant-eigene Lage Diese Steuerungen **gehoeren Ihnen, nicht Orbit.** Sie waehlen das Ziel, die Downgrade-Behandlung, die eingehende Untergrenze und die Zertifikatsabdeckung. Orbit erfasst die Richtlinie, berichtet, wie Ihre Nummern und eingehender Verkehr dagegen messen, und leitet den effektiven Zertifikatsstatus ab — es schreibt keine Ebene vor und garantiert kein STIR-Attestierungsergebnis. Die regulatorische Beurteilung darueber, welche Ebene ein gegebenes Programm halten muss, verbleibt bei Ihnen und Ihrem Rechtsrat. *** ## Verwandte Referenzen * [Uebersicht des Sprachkanals](/channels/voice/stir-shaken) — wie STIR/SHAKEN-Attestierungsebenen ueber Ihren Sprachverkehr hinweg funktionieren. * [Verify](/verify/overview) — Empfaenger-Verifizierungsfunktionen, die die Anrufer-ID-Lage ergaenzen.