Sicherheitsrichtlinien
Sicherheit der Anwendung und Features
Die Anwendungssicherheit muss schon früh berücksichtigt werden, zum Beispiel in der Prepare-Phase des Projekts, also bevor Sie die Anwendung fertigstellen und konfigurieren. Zum Schutz Ihrer Anwendung vor Hackern sowie unbefugtem Zugriff und Gebrauch müssen Sie zwei Arten von Sicherheit verwalten: die Anwendungs- und die Feature-Sicherheit.
Anwendungssicherheit
Der Schwerpunkt der Anwendungssicherheit liegt auf dem Schutz der Anwendung vor unternehmensexternen und unbefugten Benutzern. Mit der Anwendungssicherheit können Sie beispielsweise:
- das Risiko des Zugriffs auf oder des Diebstahls von Daten aus Ihrer Anwendung durch unbefugte Benutzer verringern
- befugte Benutzer identifizieren, die Zugriff auf die Anwendung benötigen
- Passwort- und Authentifizierungsrichtlinien erstellen
Für die Anwendungssicherheit sollten Sie alle Möglichkeiten zum Schutz der Anwendung (wie Sicherheitstools von Drittanbietern oder die Einrichtung einer Multi-Faktor-Authentifizierung) erwägen. Das Ziel der Anwendungssicherheit besteht darin, es unbefugten Benutzern unmöglich zu machen, die Anwendung zu verwenden, zu manipulieren, anzuzeigen oder anderweitig auf sie zuzugreifen.
Feature-Sicherheit
Der Schwerpunkt der Feature-Sicherheit liegt innerhalb der Anwendung. Hierbei wird festgelegt, auf welche Case-Typen, Features und Daten autorisierte Benutzer zugreifen dürfen. Mit der Feature-Sicherheit können Sie beispielsweise:
- Sicherheitsrollen für die in den einzelnen Case-Typen festgelegten Personas einrichten, damit autorisierte Benutzer auf benötigte Anwendungs-Features zugreifen können
- verhindern, dass Benutzer Features sehen oder auf Daten zugreifen, auf die sie keinen Zugriff haben dürften
- rollenbasierte (RBAC) und attributbasierte Zugriffskontrollen (ABAC) gestalten
Hinweis: Informationen zum Einrichten von Benutzern und Rollen finden Sie unter Benutzer zu einer Anwendung einladen.
Zum Beispiel kann der Business Owner einer Gehaltsanwendung jedem Manager die Möglichkeit geben wollen, den Gehaltsverlauf ihrer direkten Untergebenen abzufragen, nicht aber den von Kollegen oder anderen Arbeitnehmern. Außerdem soll kein Manager die Gehaltshöhe des Angestellten manuell ändern dürfen. Hingegen dürfen Gehaltsmanager und der CFO den Gehaltsverlauf aller Angestellten sehen sowie die Gehaltshöhe ändern. Bei der Dokumentation der User Story eines Managers müssen Sie dann berücksichtigen, auf welche Gehalts-Features dieser zugreifen darf.
Hinweis: Als Best Practice sollten SSA- und LSA-Teammitglieder in der Discover-Phase (Verkauf) eines Projekts die Sicherheitsbedürfnisse ermitteln und diese in der Design-Phase dokumentieren. Näheres zu den Phasen von Pega Express erfahren Sie unter dem Pega Community-Thema Pega Express Delivery.
Anwendungssicherheit innerhalb der Pega-Plattform konfigurieren
Eine Möglichkeit, um den unbefugten Zugriff auf Ihre Anwendungen einzuschränken, besteht darin, auf der Startseite Authentication in App Studio die Einstellungen im Tab Security Policies zu konfigurieren. Öffnen Sie in Dev Studio das Menü und wählen Sie Org & Security > Authentication > Security Policies aus, um die Sicherheitsrichtlinien für den gesamten Server mit der Pega-Plattform anzuzeigen und zu aktualisieren.
Vorsicht: Die Einstellungen für einen bestimmten Authentifizierungsdienst können die Einstellungen auf der Startseite für die Authentifizierung überschreiben.
Nach der Aktualisierung einer Einstellung klicken Sie am Seitenende auf , um die Aktualisierung zu erfassen. Änderungen der Sicherheitsrichtlinien werden sofort beim Absenden des Formulars aktiv.
Hinweis: Die Anwendung geeigneter Sicherheitsrichtlinien ist nur ein Aspekt der Anwendungssicherheit. Eine vollständige Liste der führenden Sicherheitspraktiken finden Sie im Modul Security-Checklisten beachten und in der Security-Checkliste für die Pega-Plattform-Implementierung.
Häufig verlangte Richtlinien
Mit den Einstellungen im Abschnitt auf dem Tab Security Policies können Sie Richtlinien für die Passwortstärke, Begrenzungen der Anzahl falscher Passworteingaben und Protokollierungsstufen für Anmeldeversuche festlegen. Der Abschnitt ist in vier Bereiche unterteilt.
- Password policies regeln die Stärke der Benutzerpasswörter
- CAPTCHA policies prüfen, ob ein Mensch ein Passwort eingegeben hat
- Lockout policies definieren das Systemverhalten bei der Eingabe eines falschen Passworts durch einen Benutzer
- Audit policy bestimmt den Umfang der Details, die bei einem Sicherheitsproblem im Systemprotokoll erfasst werden.
Sonstige Richtlinien
Die Einstellungen im Abschnitt im dem Tab Security Policies ermöglichen die Implementierung einer Multi-Faktor-Authentifizierung und die Zugriffsdeaktivierung für unbenutzte Benutzerkonten.
Tipp: Eine ausführliche Erklärung hinsichtlich der Einstellungen für jeden Richtlinientyp, einschließlich der zulässigen Mindest- und Höchstwerte, finden Sie im Hilfethema Einstellungen „Sicherheitsrichtlinien“.
Passwortrichtlinien
Im Abschnitt Passwort policies können Sie die Anforderungen an die Passwortlänge, Komplexität und Vorhersagbarkeit individuell festlegen.
Vorsicht: Im Gegensatz zu Länge und Komplexität, die Sie mit diesen Richtlinien gut regeln können, hängt die Vorhersagbarkeit teilweise vom Urteilsvermögen der Benutzer ab.
Mehr über die verfügbaren Einstellungen erfahren Sie, wenn Sie in der folgenden Abbildung auf die Pluszeichen (+) klicken.
CAPTCHA- und Sperrrichtlinien
Um einen Brute-Force-Angriff zu stoppen oder zu verlangsamen, beschränken Sie die Anzahl der Fehlanmeldungen. Sie können z. B. verlangen, dass nach einem dritten Fehlversuch weitere Versuche für 15 Minuten blockiert werden. Es gibt zwei Vorgehensweisen, um den Benutzer nach zu vielen falschen Eingaben auszubremsen: CAPTCHAs und Sperren.
CAPTCHA-Richtlinien
Ein CAPTCHA ist eine an eine Aufgabe gebundene Prüfung, bei der festgestellt wird, ob ein Benutzer ein Mensch ist. Bei einem CAPTCHA werden den Benutzern üblicherweise mehrere Bilder gezeigt und die Benutzer müssen ein bestimmtes Objekt erkennen. So kann z. B. ein CAPTCHA einem Benutzer ein Bild mit Buchstaben- oder Zahlenfolge (oder beidem) zeigen, die der Benutzer in ein Textfeld eingeben muss. Im Bild können die Zeichen gedehnt oder verzerrt werden, um ihre Lesbarkeit mithilfe automatisierter Zeichenerkennungstechniken zu erschweren. Das folgende Bild zeigt, wie die Pega-Plattform einen Benutzer mit einem CAPTCHA überprüft.
Verwenden Sie den Abschnitt CAPTCHA policies, um ein CAPTCHA, um Anmeldeversuche zu aktivieren und zu konfigurieren und so Anmeldeversuche zu überprüfen. Bei Aktivierung können Sie:
- zwischen der Standardimplementierung oder einer benutzerdefinierten Implementierung auswählen
- ein CAPTCHA bei der Erstanmeldung verwenden
- die Wahrscheinlichkeit festlegen, wann dem Benutzer nach einem gescheiterten Anmeldeversuch ein CAPTCHA angezeigt wird
Sperr-Richtlinien
Wenn Benutzer das Passwort mehrmals falsch eingegeben haben, können Sie den Zugang sperren und eine Wartezeit bis zum nächsten Anmeldeversuch festlegen. Sperren können einen Brute-Force-Angriff verlangsamen oder verhindern.
Passen Sie im Abschnitt Lockout policies an, wann und wie lange Benutzer nach einem fehlgeschlagenen Anmeldeversuch warten müssen. Die angeführten Möglichkeiten orientieren sich daran, ob die Sperrrichtlinie aktiviert oder deaktiviert ist. Bei aktivierter Sperrsanktion können Sie:
- einen Schwellenwert für fehlgeschlagene Anmeldeversuche einstellen
- die Dauer der Erstsperre in Sekunden festlegen (wiederholte Anmeldefehler erhöhen die Sperrsanktion erheblich)
- ein Protokoll mit Anmeldefehlern führen, das eine bestimmte Minutenanzahl umfasst
Bei deaktivierter Sperrsanktion können Sie:
- die Anzahl der zulässigen fehlgeschlagenen Anmeldeversuche festlegen, ehe ein Konto gesperrt wird
- die Sperrdauer des Benutzerkontos in Minuten festlegen
Verschieben Sie in der Mitte des folgenden Bildes die vertikale Linie und vergleichen Sie die aktivierten und die deaktivierten Sperrrichtlinien.
Prüfrichtlinie
Verwenden Sie den Abschnitt Audit policy, um die Detailtiefe der erfassten Anmeldeversuche anzupassen. Wenn Sie nur Anmeldefehler aufzeichnen möchten, setzen Sie die Protokollstufe auf Basic. Wenn Sie gescheiterte Anmeldeversuche und erfolgreiche Anmeldungen aufzeichnen möchten, setzen Sie die Protokollstufe auf Advanced.
Berücksichtigen Sie die Prüfrichtlinie im Gehaltsabrechnungsszenario. Möglicherweise möchte der Business Owner die Änderungen der Gehaltshöhe eines Mitarbeiters durch einen Gehaltsmanager prüfen, um sich zu vergewissern, dass Gehaltserhöhungen nicht ohne offizielle Genehmigung erfolgen.
Multi-Faktor-Authentifizierungs-Richtlinien
Passwörter stellen eine Möglichkeit der Benutzerauthentifizierung dar. Um die Sicherheit zu erhöhen, aktivieren Sie im Hinblick auf die Benutzerprüfung die Multi-Faktor-Authentifizierung. Mit der Multi-Faktor-Authentifizierung erlangen Benutzer Zugriff, nachdem sie mehrere Faktoren oder Angaben bereitstellen, die ihre Identität bestätigen.
- Knowledge – etwas, das nur die Benutzer wissen, z. B. ein Passwort
- Possession – etwas, das nur die Benutzer haben, z. B. ein Mobilgerät
- Inheritance – eine Besonderheit der Benutzer, wie z. B. ihr Standort
Hinweis: Bei der Zwei-Faktoren-Authentifizierung handelt es sich um eine Untergruppe der Multi-Faktor-Authentifizierung, bei der die Benutzer bei der Anmeldung zwei Beweiselemente erbringen.
Die Pega-Plattform bietet ein Standard-Feature zur Multi-Faktor-Authentifizierung, mit dem den Benutzern per E-Mail oder SMS ein Einmalpasswort gesendet wird. Zum Abschließen des Anmeldevorgangs müssen die Benutzer das Einmalpasswort innerhalb der vorgegebenen Zeit eingeben. Im Abschnitt Multi-Faktor-Authentifizierungs-Richtlinien (mit Einmalpasswort) konfigurieren und richten Sie dieses Einmalpasswort ein.
Um mehr über die Einstellungen für die Multi-Faktor-Authentifizierung zu erfahren, klicken Sie in der folgenden Abbildung auf die Pluszeichen (+).
Operator-Deaktivierungsrichtlinie
Im Abschnitt Operator disablement policy wird automatisch der Zugriff für Benutzer deaktiviert, die für die angegebene Anzahl von Tagen inaktiv sind. Damit das System den Zugriff für Benutzer, die Zugriff benötigen, nicht sperrt, fügen Sie den Operator-ID-Datensatz für diese Benutzer zur Liste Exclusion list of operator IDs hinzu.
Beispiel für die Deaktivierung von Benutzern ist eine Situation, in der ein Benutzer, der für eine Gemeindekolumne schreibt, seit über einem Jahr keinen Inhalt auf einer WordPress-Site veröffentlicht hat, oder ein krankgeschriebener Mitarbeiter sich seit über 90 Tagen nicht als Administrator am Mitarbeiter-Trainingsportal angemeldet hat. Denkbar ist auch eine Situation, in der ein CFO nicht deaktiviert wurde, obwohl er nur zur Jahresabschlussprüfung auf das System zugreift.
Hinweis: Entscheiden Sie, welchen Benutzern der Zugriff auch dann möglich sein soll, wenn sie das System nur selten benutzen.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen.
Prüfen Sie mit der folgenden Interaktion Ihr Wissen.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Möchten Sie uns dabei helfen, diesen Inhalt zu verbessern?