Teil I Übersicht über die Sicherheit
1. Sicherheitsservices (Überblick)
Teil II System-, Datei- und Gerätesicherheit
2. Verwalten von Rechnersicherheit (Übersicht)
3. Steuern des Zugriffs auf Systeme (Aufgaben)
4. Steuern des Zugriffs auf Geräte (Aufgaben)
5. Verwenden von Basic Audit Reporting Tool (Aufgaben)
6. Steuern des Zugriffs auf Dateien (Aufgaben)
7. Verwenden von Automated Security Enhancement Tool (Aufgaben)
Teil III Rollen, Berechtigungsprofile und Berechtigungen
8. Verwenden von Rollen und Berechtigungen (Übersicht)
9. Rollenbasierte Zugriffssteuerung (Aufgaben)
10. Rollenbasierte Zugriffssteuerung (Übersicht)
Teil IV Kryptografische Services
13. Oracle Solaris Cryptographic Framework (Übersicht)
14. Oracle Solaris Cryptographic Framework (Aufgaben)
15. Oracle Solaris Key Management Framework
Teil V Authentifizierungsservices und sichere Kommunikation
16. Verwenden von Authentifizierungsservices (Aufgaben)
19. Verwenden von Oracle Solaris Secure Shell (Aufgaben)
20. Oracle Solaris Secure Shell (Referenz)
21. Einführung zum Kerberos-Service
22. Planen des Kerberos-Service
23. Konfigurieren des Kerberos-Service (Aufgaben)
24. Kerberos-Fehlermeldungen und -Fehlerbehebung
25. Verwalten von Kerberos-Hauptelementen und Richtlinien (Aufgaben)
26. Verwenden von Kerberos-Anwendungen (Aufgaben)
27. Der Kerberos-Service (Referenz)
Teil VII Prüfung bei Oracle Solaris
28. Prüfung bei Oracle Solaris (Übersicht)
29. Planen der Oracle Solaris-Prüfung
Planen der Oracle Solaris-Prüfung (Übersicht der Schritte)
Planen der Oracle Solaris-Prüfung (Aufgaben)
So planen Sie die Prüfung der Zonen
So planen Sie Speicherplatz für Prüfdatensätze
So planen Sie die zu prüfenden Personen und Objekte
Steuerung des Prüfungsaufwands
Höhere Verarbeitungszeit der Prüfungsdaten
Aufwand für Analyse der Prüfungsdaten
Aufwand für Speicherung der Prüfungsdaten
30. Verwalten der Oracle Solaris-Prüfung (Aufgaben)
Die Prüfrichtlinie bestimmt die Merkmale der Prüfdatensätze für das lokale System. Die Richtlinienoptionen werden vom Startskript festgelegt. Das Skript bsmconv, durch das der Prüfservice aktiviert wird, erstellt das Skript /etc/security/audit_startup. Das Skript audit_startup führt den Befehl auditconfig aus, um die Prüfrichtlinie festzulegen. Weitere Informationen zum Skript erhalten Sie auf der Manpage audit_startup(1M).
Die meisten Prüfrichtlinienoptionen sind standardmäßig deaktiviert, damit der Bedarf an Speicherplatz und Systemverarbeitung so gering wie möglich gehalten wird. Mit dem Befehl auditconfig können Sie Prüfrichtlinienoptionen dynamisch aktivieren oder deaktivieren. Mit dem Skript audit_startup können Sie Richtlinienoptionen dauerhaft aktivieren oder deaktivieren.
Stellen Sie anhand der folgenden Tabelle fest, ob die Anforderungen an Ihrem Standort den zusätzlichen Aufwand rechtfertigen, der durch Aktivieren von mindestens einer Prüfrichtlinienoption entstehen würde.
Tabelle 29-1 Auswirkungen der Prüfrichtlinienoptionen
Durch die Richtlinien ahlt und cnt werden die durchzuführenden Aktionen festgelegt, wenn die Prüfwarteschlange voll ist und keine weiteren Ereignisse speichern kann. Die Richtlinien sind unabhängig und miteinander verbunden. Die Kombination der Richtlinien hat folgende Auswirkungen:
-ahlt +cnt ist die standardmäßige Richtlinie, die übersprungen wird. Diese Standardwerte ermöglichen die Verarbeitung eines geprüften Ereignisses, auch wenn das Ereignis nicht protokolliert werden kann.
Die Richtlinie -ahlt legt fest, dass, wenn ein Prüfdatensatz eines asynchronen Ereignisses nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, das System die Anzahl der Ereignisse zählt und die Verarbeitung fortsetzt. In der globalen Zone wird durch den Zähler as_dropped die Anzahl aufgezeichnet.
Die Richtlinie +cnt legt fest, dass, wenn ein synchrones Ereignis eintritt und nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, das System das Ereignis zählt und die Verarbeitung fortsetzt. Der Zähler as_dropped der Zone erfasst die Anzahl.
Die Konfiguration -ahlt +cnt wird normalerweise an Standorten verwendet, an denen die Verarbeitung fortgesetzt werden muss, auch wenn durch das Fortsetzen der Verarbeitung die Prüfdatensätze verloren gehen könnten. Das Feld auditstatdrop zeigt die Anzahl der Prüfdatensätze, die in einer Zone übersprungen wurden.
Die Richtlinie +ahlt -cnt legt fest, dass die Verarbeitung angehalten wird, wenn ein Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann.
Die Richtlinie +ahlt legt fest, dass, wenn ein Prüfdatensatz eines asynchronen Ereignisses nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, die gesamte Verarbeitung angehalten wird. Das System wird in einen Alarmzustand versetzt. Das asynchrone Ereignis ist nicht in der Prüfwarteschlange enthalten und muss von den Zeigern im Aufruf-Stack wiederhergestellt werden.
Die Richtlinie -cnt legt fest, dass, wenn ein synchrones Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, der Thread, der das Ereignis zustellen möchte, blockiert wird. Der Thread wird zu einer Passivwarteschlange hinzugefügt, bis Prüfbereich verfügbar ist. Es wird keine Zählung durchgeführt. Die Programme scheinen blockiert zu sein, bis Prüfbereich verfügbar ist.
Die Konfiguration +ahlt -cnt wird normalerweise an Standorten verwendet, bei denen ein Datensatz der einzelnen Prüfereignisse Vorrang vor der Systemverfügbarkeit hat. Die Programme scheinen blockiert zu sein, bis Prüfbereich verfügbar ist. Das Feld auditstat wblk zeigt, wie oft Threads blockiert wurden.
Wenn jedoch ein asynchrones Ereignis eintritt, löst dies den Alarmzustand und Ausfall des Systems aus. Die Kernel-Warteschlange der Prüfereignisse kann aus einem Speicherabzug manuell wiederhergestellt werden. Das asynchrone Ereignis ist nicht in der Prüfwarteschlange enthalten und muss von den Zeigern im Aufruf-Stack wiederhergestellt werden.
Die Richtlinie -ahlt -cnt legt fest, dass, wenn ein asynchrones Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, das Ereignis gezählt und die Verarbeitung fortgesetzt wird. Wenn ein synchrones Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, wird der Thread, der das Ereignis zustellen möchte, blockiert. Der Thread wird zu einer Passivwarteschlange hinzugefügt, bis Prüfbereich verfügbar ist. Es wird keine Zählung durchgeführt. Die Programme scheinen blockiert zu sein, bis Prüfbereich verfügbar ist.
Die Konfiguration -ahlt -cnt wird normalerweise an Standorten verwendet, an denen die Aufzeichnung aller synchronen Prüfereignisse Vorrang vor möglichem Verlust asynchroner Prüfdatensätze hat. Das Feld auditstat wblk zeigt, wie oft Threads blockiert wurden.
Die Richtlinie +ahlt +cnt legt fest, dass, wenn ein asynchrones Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, das System in einen Alarmzustand versetzt wird. Wenn ein synchrones Ereignis nicht zur Kernel-Prüfwarteschlange hinzugefügt werden kann, zählt das System das Ereignis und setzt die Verarbeitung fort.