Entscheiden, wo Sicherheit erzwingt werden soll
Kompromisse sind inhärent bei der Durchsetzung von Sicherheit. Eine Datenbank kann ein natürlicher Ort sein, um Sicherheitslogik zu setzen, da diese Daten letztendlich das wichtigste zu schützende Element sind. Dies hat jedoch erhebliche Auswirkungen auf die Leistung. Das Erzwingen von Sicherheit in der Datenbank kann sehr teuer sein, lässt sich schlecht skalieren und ist unflexibel.
Erzwingen von Sicherheit in der mittleren Ebene
Die allgemeine Regel für skalierbare Anwendungen mit mehreren Ebenen mit COM+ ist, dass Sie nach Möglichkeit detaillierte Sicherheit in der COM+-Anwendung auf der mittleren Ebene erzwingen sollten. Auf diese Weise können Sie die von COM+ bereitgestellten skalierbaren Dienste vollständig nutzen. Erzwingen Sie die Authentifizierung in der Datenbank nur dann, wenn Sie dies unbedingt benötigen, und wägen Sie die auswirkungen auf die Leistung vollständig ab.
Die optimale Situation besteht darin, Datenbanktabellen so schützen zu können, dass die COM+-Anwendung unter ihrer eigenen Identität darauf zugreifen kann. Die Datenbank sollte nur die COM+-Anwendung authentifizieren und ihr vertrauen, um Clients, die auf Daten zugreifen, ordnungsgemäß zu authentifizieren und zu autorisieren. Dieser Ansatz bietet folgende Vorteile:
- Es ermöglicht das Verbindungspooling zwischen allen Clients, da Verbindungen vollständig generisch sind.
- Es optimiert im Allgemeinen den Datenzugriff, oft ein problematischer Drosselpunkt beim Skalieren von Anwendungen.
- Es kann den Logikaufwand für die Erzwingung von Sicherheit minimieren, insbesondere wenn die deklarative rollenbasierte Sicherheit verwendet werden kann.
- Es kann eine große Flexibilität in einer Sicherheitsrichtlinie bieten. Sie können sie ganz einfach konfigurieren und neu konfigurieren, wie unter Rollenbasierte Sicherheitsverwaltung beschrieben.
Wie unter Effektives Entwerfen von Rollen erläutert, können Rollen zwar einfach und effektiv auf einige Benutzer-Daten-Beziehungen angewendet werden, aber sie sind keine universelle Lösung für Sicherheitszugriffsentscheidungen.
Erzwingen der Sicherheit in der Datenbank
Obwohl es vorzuziehen ist, Sicherheit auf der mittleren Ebene zu erzwingen, gibt es eine Reihe von Gründen, die Sicherheit in der Datenbank zu erzwingen, z. B.:
- Sie haben keine Wahl, vielleicht aus legacy-Gründen oder vielleicht, weil die Entscheidung einfach nicht in Ihren Händen liegt.
- Auf die Datenbank wird von einer Vielzahl von Anwendungen zugegriffen, und ihre Sicherheit kann nicht auf der Grundlage einer einzelnen Anwendung konfiguriert werden.
- Eine Datenbank kann vorhersagbar geschützt werden. Wenn Sie unternehmenskritische Daten in einer Datenbank aufbewahren, können Sie einen engen Wagen um sie herum zeichnen und dabei helfen, zu steuern, wer sie sehen kann.
- Die Authentifizierung der ursprünglichen Clients in der Datenbank ermöglicht eine detaillierte Protokollierung darüber, wer was in der Datenbank ausgeführt hat.
- Einige Daten sind an bestimmte Benutzer gebunden, und die Logik, extrem differenzierte Zugriffsentscheidungen zu treffen, kann am effizientesten in der Datenbank selbst durchgeführt werden, in der Nähe der Daten.
Wenn Sie den Luxus haben, die Sicherheit der Datenbank und der COM+-Anwendung gemeinsam zu entwerfen, betreffen die meisten dieser Probleme die Merkmale der Daten selbst und ihre Beziehung zu den Benutzern, die darauf zugreifen. Mit Daten, auf die vorhersagbare Benutzerkategorien zugreifen können, ist es effizient, den Zugriff auf der mittleren Ebene mithilfe von Rollen zu steuern. Bei Daten, die kompliziert an sehr kleine Benutzerklassen gebunden sind, müssen diese Beziehungen häufig mit den Daten selbst ausgedrückt werden, sodass Sie eine gewisse Sicherheit in der Datenbank erzwingen müssen.
Leistungsauswirkungen der Erzwingung der Sicherheit in der Datenbank
Wenn Sie Benutzer in der Datenbank authentifizieren oder autorisieren, muss die Benutzeridentität an die Datenbank weitergegeben werden, um dies zu unterstützen. Wenn die Datenbank dazu der Anwendung der mittleren Ebene vertraut, ist es möglich, Benutzersicherheitsinformationen in Parametern zu übergeben. Andernfalls muss der Aufruf der Datenbank unter der Identität des Benutzers erfolgen, was bedeutet, dass die Serveranwendung die Identität des Clients annehmen muss. Dies kann Auswirkungen auf die Leistung haben, z. B. die folgenden:
- Der Identitätswechsel des Clients kann viel langsamer sein, als den Aufruf direkt unter der Anwendungsidentität zu tätigen. Weitere Informationen finden Sie unter Clientidentitätswechsel und Delegierung.
- Eine Datenbankverbindung, die unter einer bestimmten Benutzeridentität hergestellt wird, kann nicht im Pool zusammengefasst werden.
- Durch das Hinzufügen von Logik in der Datenbank selbst besteht das Risiko, dass ein Skalierungsengpass entsteht.
Zugehörige Themen