Autorisierung
Machen Sie jede betroffene Zugriffsentscheidung explizit, setzen Sie sie an der echten Grenze durch und weisen Sie sowohl erlaubtes als auch verweigertes Verhalten nach. Arbeiten Sie innerhalb des angeforderten Flows; das Laden dieses Skills startet kein ganzheitliches Anwendungs-Audit. Verwenden Sie vorhandene Identität, Richtlinie und Domain-Eigentümer, bevor Sie ein neues Framework einführen.
Richtlinie definieren
Lesen Sie akzeptierte Produktentscheidungen und tatsächliche Aufrufer. Notieren Sie eine kleine Richtlinienmatrix für den geänderten Flow: Prinzipal, Operation, Ressource, relevante Beziehung/Bereich/Zustand, erlaubte Eingabe-/Ausgabefelder und Ergebnis. Verwenden Sie Rollen, Attribute, Besitz oder Fähigkeiten entsprechend dem tatsächlichen Bedarf; eine Rolle allein kann keinen Zugriff auf einen bestimmten Datensatz herstellen. Bewahren Sie bewusst unterschiedliche Lese-, Schreib-, Export-, Freigabe- und Administratorberechtigungen.
Trennen Sie die Identitätsauthentifizierung von der Berechtigung zum Handeln. Beziehen Sie Identität und Berechtigungen aus dem vertrauenswürdigen Sitzungs-, Token- oder Dienstkontext. Anforderungs-IDs, Mandantenselektoren, Rollenfelder und UI-Zustand wählen oder beschreiben eine Anfrage; sie verleihen keine Autorität. Anonymer/öffentlicher Zugriff kann explizit erlaubt oder fähigkeitsbezogen eingeschränkt werden. Fehlende Identität oder fehlender Bereich darf nicht stillschweigend zu einer globalen Systemberechtigung werden. Halten Sie privilegierte Betreiber und Identitätswechsel explizit und zurechenbar.
Setzen Sie für nicht zugeordneten Zugriff standardmäßig auf Verweigerung und verwenden Sie die geringste Autorität, die der akzeptierten Richtlinie genügt. Eine unentschiedene geschäftliche Berechtigung ist eine Produktfrage, keine Einladung, eine freizügige Voreinstellung zu erfinden. Setzen Sie die unabhängige Arbeit fort, während diese Wahl ungelöst bleibt. Halten Sie eine bewusst lokale, nicht geteilte Demo getrennt von einem Dienst, der echte geschützte Daten bereitstellt.
Jeden betroffenen Zugriffspfad finden
Folgen Sie der betroffenen Ressource durch ihre tatsächlichen Einstiegspunkte und Eigentümer. Beziehen Sie relevante Web-/Mobile-APIs, servergerenderte Loader, Aktionen, Importe, Batch-Operationen, Jobs und Integrationen ein. Überprüfen Sie Suche/Zählen/Export, Dateien, Caches und Abonnements, wenn sie dieselben geschützten Fakten offenlegen. Lesen Sie Zugriffsoberflächen für diese Pfade oder für Fähigkeiten, Delegation und Widerruf; wählen Sie die zutreffenden Abschnitte aus.
Benennen Sie den Richtlinieneigentümer und die Durchsetzungspunkte. Zentralisieren Sie die Bedeutung der Regel, während Sie sie überall dort durchsetzen, wo Daten oder Effekte Vertrauensgrenzen überschreiten. Eine Middleware-Anmeldeprüfung, UI-Schutz, UUID oder ein früherer erfolgreicher Lesevorgang reichen allein nicht aus. Eine Framework-Richtlinie, Datenbankrichtlinie oder ein bereichsbezogener Besitzer kann funktionieren; überprüfen Sie die tatsächliche Konfiguration und Laufzeitberechtigungen, anstatt anzunehmen, dass sie Umgehungswege abdeckt.
Entscheidung durchsetzen
Für Lesevorgänge schränken Sie die autorisierte Ressourcenpopulation ein, bevor Ergebnisse die vertrauenswürdige Grenze verlassen, und schränken Sie zurückgegebene Felder ein. Wenden Sie eine äquivalente Richtlinie auf verwandte Objekte und alternative Darstellungen an. Verwenden Sie die Offenlegungsrichtlinie des Produkts für fehlende versus verbotene Ressourcen; Fehler, Zählungen und serialisierte Eigenschaften können ebenfalls geschützte Fakten offenlegen.
Für Mutationen validieren Sie die Aktion, das Ziel und die resultierenden Beziehungen, einschließlich benutzerdefinierter Fremdschlüssel und geschützter Felder. Verwenden Sie erlaubte Eingabefelder, anstatt eine gesamte Anfrage an eine dauerhafte Entität zu binden. Wenn eine erreichbare Verschachtelung die Berechtigung ungültig machen kann, setzen Sie Bereich, Mitgliedschaft oder Zustand bei der Auswirkung durch, indem Sie die geeignete atomare Sperre oder Serialisierung des Speichers verwenden. Gekoppelte Kinder und Nebeneffekte folgen derselben Zulassung. Behalten Sie einen vorhandenen vollständigen Eigentümer; fügen Sie keinen weiteren Geschäftsschreiber hinzu, nur um Autorisierungsprüfungen einzufügen.
Definieren Sie, wann Berechtigungen ausgewertet werden und wann eine Änderung wirksam wird. Aktueller Zugriff, unveränderliche historische Zuordnung und eine zuvor akzeptierte dauerhafte Verpflichtung sind unterschiedliche Verträge. Wiederholungen, verzögerte Zustellung und delegierte Aufgaben benötigen eine explizite Autorität/Lebensdauer; weder veraltete Benutzeransprüche noch eine generische Systemidentität beantworten diese Frage. Wenden Sie Widerruf und Wiederherstellung gemäß diesem Vertrag an, ohne gültige Verpflichtungen stillschweigend zu stornieren oder deren Publikum zu erweitern.
Grenze nachweisen
Leiten Sie einen kleinen, diskriminierenden Testsatz aus der Richtlinienmatrix ab. Zeigen Sie durch den echten Eigentümer und die relevante bereitgestellte Grenze, dass ein gültiger Akteur die Operation abschließt, und bedeutungsvolle Verweigerungen: ein anderer Eigentümer im selben Mandanten, ein anderer Mandant, eine schwächere Rolle, anonyme/fehlerhafte Fähigkeit oder geänderte Berechtigung, wo zutreffend. Verwenden Sie tatsächliche Ziel-Datensätze und explizite Köder; bestätigen Sie geschützte Felder, unveränderte dauerhafte Effekte und nicht verwandte Datensätze. Wählen Sie relevante Fälle aus, anstatt jede theoretische Kombination zu proben.
Eine simulierte Richtlinie, die „wahr“ oder „falsch“ zurückgibt, beweist weder ihre Entscheidung noch die Abfrage-/Schreibbeschränkung. Testen Sie tatsächliche Prädikate oder Speicherrichtlinien mit realistischer Laufzeit-Autorität. Für UI-Zugriffsansprüche verifizieren Sie eine direkte Anfrage unabhängig von der Sichtbarkeit von Schaltflächen. Untersuchen Sie nicht die Identitäten anderer Personen oder gemeinsame/ Live-Daten; verwenden Sie isolierte autorisierte Testdaten. Trennen Sie statische Erkenntnisse, vorgeschlagene Prüfungen, ausgeführte Tests und Lücken in der Bereitstellungsrichtlinie.
Liefern Sie die Richtlinie, autoritative Quellen, betroffene Pfade, Durchsetzung und Nachweise sowie ungelöste Produktentscheidungen oder externe Konfiguration. Ein bestandener Test ist auf diese Pfade beschränkt; das Verfahren zertifiziert nicht die Gesamtsicherheit der Anwendung.