Verschlüsselungsrisiken und Schutzfunktionen
Microsoft 365 folgt einem Kontroll- und Complianceframework, das sich auf Risiken für den Dienst und die Kundendaten konzentriert. Der Dienst implementiert eine große Reihe von technologie- und prozessbasierten Methoden, die als Kontrollen bezeichnet werden, um diese Risiken zu mindern. Die Identifizierung, Bewertung und Entschärfung von Risiken durch Kontrollen ist ein kontinuierlicher Prozess.
Die Implementierung von Steuerelementen innerhalb der Ebenen unserer Clouddienste wie Einrichtungen, Netzwerke, Server, Anwendungen, Benutzer (z. B. Microsoft-Administratoren) und Daten bildet eine umfassende Verteidigungsstrategie. Der Schlüssel zu dieser Strategie besteht darin, dass viele verschiedene Steuerelemente auf verschiedenen Ebenen implementiert werden, um sich vor denselben oder ähnlichen Risikoszenarien zu schützen. Dieser mehrschichtige Ansatz bietet ausfallsicheren Schutz für den Fall, dass ein Steuerelement ausfällt.
In dieser Tabelle sind einige Risikoszenarien und die derzeit verfügbaren Verschlüsselungstechnologien aufgeführt, mit denen diese entschärft werden. In vielen Fällen werden diese Szenarien auch durch andere in Microsoft 365 implementierte Steuerelemente entschärft.
Verschlüsselungstechnologie | Dienste | Schlüsselverwaltung | Risikoszenario | Wert |
---|---|---|---|---|
BitLocker | Exchange und SharePoint | Microsoft | Datenträger oder Server werden gestohlen oder nicht ordnungsgemäß wiederverwendet. | BitLocker bietet einen ausfallsicheren Ansatz zum Schutz vor Datenverlusten aufgrund gestohlener oder nicht ordnungsgemäß wiederverwendeter Hardware (Server/Datenträger). |
Dienstverschlüsselung | SharePoint und OneDrive; Umtausch | Microsoft | Interner oder externer Hacker versucht, als Blob auf einzelne Dateien/Daten zuzugreifen. | Die verschlüsselten Daten können nicht ohne Zugriff auf Schlüssel entschlüsselt werden. Trägt dazu bei, das Risiko eines Hackerzugriffs auf Daten zu verringern. |
Kundenschlüssel | SharePoint, OneDrive und Exchange | Kunde | Nicht zutreffend (Dieses Feature ist als Compliancefeature konzipiert, nicht als Risikominderung.) | Unterstützung von Kunden bei der Erfüllung interner Vorschriften und Complianceverpflichtungen sowie der Möglichkeit, den Dienst zu verlassen und Microsoft den Zugriff auf Daten zu entziehen |
Transport Layer Security (TLS) zwischen Microsoft 365 und Clients | Exchange, SharePoint, OneDrive, Teams und Viva Engage | Microsoft, Kunde | Man-in-the-Middle- oder anderen Angriff, um den Datenfluss zwischen Microsoft 365 und Clientcomputern über das Internet zu tippen. | Diese Implementierung bietet sowohl für Microsoft als auch für Kunden einen Mehrwert und stellt die Datenintegrität sicher, während sie zwischen Microsoft 365 und dem Client fließt. |
TLS zwischen Microsoft-Rechenzentren | Exchange, SharePoint und OneDrive | Microsoft | Man-in-the-Middle- oder andere Angriffe, um den Kundendatenfluss zwischen Microsoft 365-Servern in verschiedenen Microsoft-Rechenzentren zu nutzen. | Diese Implementierung ist eine weitere Methode zum Schutz von Daten vor Angriffen zwischen Microsoft-Rechenzentren. |
Azure Rights Management (Azure RMS) (enthalten in Microsoft 365 oder Azure Information Protection) | Exchange, SharePoint und OneDrive | Kunde | Daten fallen in die Hände einer Person, die keinen Zugriff auf die Daten haben sollte. | Azure Information Protection verwendet Azure RMS, das Kunden einen Mehrwert bietet, indem Verschlüsselungs-, Identitäts- und Autorisierungsrichtlinien verwendet werden, um Dateien und E-Mails auf mehreren Geräten zu schützen. Azure RMS bietet Konfigurationsoptionen, bei denen alle E-Mails, die von Microsoft 365 stammen und bestimmte Kriterien erfüllen (z. B. alle E-Mails an eine bestimmte Adresse), automatisch verschlüsselt werden können, bevor sie an einen anderen Empfänger gesendet werden. |
S/MIME | Exchange | Kunde | Eine Person, die nicht der beabsichtigte Empfänger ist, hat eine E-Mail erhalten. | S/MIME trägt dazu bei, dass nur der beabsichtigte Empfänger eine verschlüsselte E-Mail entschlüsseln kann. |
Microsoft Purview-Nachrichtenverschlüsselung | Exchange, SharePoint | Kunde | Eine Person, die nicht der beabsichtigte Empfänger ist, hat eine E-Mail und ihre geschützten Anlagen erhalten. | Mit der Nachrichtenverschlüsselung können Sie Ihren Mandanten so konfigurieren, dass E-Mails von Microsoft 365, die bestimmten Kriterien entsprechen (z. B. alle E-Mails an eine bestimmte Adresse), automatisch verschlüsselt werden, bevor sie gesendet werden. |
SMTP-TLS (Simple Mail Transfer Protocol) mit Partner-organization | Exchange | Kunde | Email wird während der Übertragung von einem Microsoft 365-Mandanten zu einem Partner organization über einen Man-in-the-Middle-Angriff oder einen anderen Angriff abgefangen. | Ermöglicht ihnen das Senden und Empfangen aller E-Mails zwischen Ihrem Microsoft 365-Mandanten und der E-Mail-organization Ihres Partners innerhalb eines verschlüsselten SMTP-Kanals. |
Tipp
Wenn Sie kein E5-Kunde sind, verwenden Sie die 90-tägige Testversion von Microsoft Purview-Lösungen, um zu erfahren, wie zusätzliche Purview-Funktionen Ihre Organisation bei der Verwaltung von Datensicherheits- und Complianceanforderungen unterstützen können. Beginnen Sie jetzt im Microsoft Purview-Testversionshub. Erfahren Sie mehr über Anmelde- und Testbedingungen.
In mehrinstanzenfähigen Umgebungen verfügbare Verschlüsselungstechnologien
Verschlüsselungstechnologie | Implementiert von | Schlüsselaustauschalgorithmus und -stärke | Schlüsselverwaltung* | Federal Information Processing Standards (FIPS) 140-2 validiert |
---|---|---|---|---|
BitLocker | Exchange | Advanced Encryption Standard (AES) 256-Bit | Der externe AES-Schlüssel wird in einem Geheimnissafe und in der Registrierung des Exchange-Servers gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja |
SharePoint | AES 256-Bit | Externer AES-Schlüssel wird in einem Geheimnissafe gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja | |
Skype for Business | AES 256-Bit | Externer AES-Schlüssel wird in einem Geheimnissafe gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja | |
Dienstverschlüsselung | SharePoint | AES 256-Bit | Die Schlüssel, die zum Verschlüsseln der Blobs verwendet werden, werden in der SharePoint-Inhaltsdatenbank gespeichert. Die SharePoint-Inhaltsdatenbank wird durch Datenbankzugriffssteuerungen und Verschlüsselung ruhender Daten geschützt. Die Verschlüsselung erfolgt mithilfe der transparenten Datenverschlüsselung (Transparent Data Encryption, TDE) in Azure SQL-Datenbank. Diese Geheimnisse befinden sich auf der Dienstebene für SharePoint, nicht auf Mandantenebene. Diese Geheimnisse (manchmal auch als master Schlüssel bezeichnet) werden in einem separaten sicheren Repository gespeichert, das als Schlüsselspeicher bezeichnet wird. TDE bietet Sicherheit im Ruhezustand sowohl für die aktive Datenbank als auch für die Datenbanksicherungen und Transaktionsprotokolle. Wenn Kunden den optionalen Schlüssel angeben, wird der Schlüssel in Azure Key Vault gespeichert, und der Dienst verwendet den Schlüssel zum Verschlüsseln eines Mandantenschlüssels, der zum Verschlüsseln eines Standortschlüssels verwendet wird, der dann zum Verschlüsseln der Schlüssel auf Dateiebene verwendet wird. Im Wesentlichen wird eine neue Schlüsselhierarchie eingeführt, wenn der Kunde einen Schlüssel bereitstellt. | Ja |
Skype for Business | AES 256-Bit | Jedes Datenstück wird mit einem anderen zufällig generierten 256-Bit-Schlüssel verschlüsselt. Der Verschlüsselungsschlüssel wird in einer entsprechenden METADATEN-XML-Datei gespeichert, die durch einen konferenzspezifischen master-Schlüssel verschlüsselt wird. Der master Schlüssel wird auch einmal pro Konferenz nach dem Zufallsprinzip generiert. | Ja | |
Exchange | AES 256-Bit | Jedes Postfach wird mit einer Datenverschlüsselungsrichtlinie verschlüsselt, die von Microsoft oder dem Kunden (bei Verwendung des Kundenschlüssels) kontrollierte Verschlüsselungsschlüssel verwendet. | Ja | |
TLS zwischen Microsoft 365 und Clients/Partnern | Exchange | Opportunistisches TLS, das mehrere Verschlüsselungssammlungen unterstützt | Das TLS-Zertifikat für Exchange (outlook.office.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für Exchange ist ein 2048-Bit-SHA1RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja, wenn TLS 1.2 mit 256-Bit-Verschlüsselungsstärke verwendet wird |
SharePoint | TLS 1.2 mit AES 256 Datenverschlüsselung in OneDrive und SharePoint |
Das TLS-Zertifikat für SharePoint (*.sharepoint.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für SharePoint ist ein 2048-Bit-SHA1RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja | |
Microsoft Teams | TLS 1.2 mit AES 256 Häufig gestellte Fragen zu Microsoft Teams – Admin Hilfe |
Das TLS-Zertifikat für Microsoft Teams (teams.microsoft.com, edge.skype.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für Microsoft Teams ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja | |
TLS zwischen Microsoft-Rechenzentren | Alle Microsoft 365-Dienste | TLS 1.2 mit AES 256 Secure Real-Time Transport Protocol (SRTP) |
Microsoft verwendet eine intern verwaltete und bereitgestellte Zertifizierungsstelle für die Server-zu-Server-Kommunikation zwischen Microsoft-Rechenzentren. | Ja |
Azure Rights Management (enthalten in Microsoft 365 oder Azure Information Protection) | Exchange | Unterstützt kryptografischen Modus 2, eine aktualisierte und erweiterte RMS-Kryptografieimplementierung. Es unterstützt RSA 2048 für Signatur und Verschlüsselung und SHA-256 für Hash in der Signatur. | Verwaltet von Microsoft. | Ja |
SharePoint | Unterstützt kryptografischen Modus 2, eine aktualisierte und erweiterte RMS-Kryptografieimplementierung. Es unterstützt RSA 2048 für Signatur und Verschlüsselung und SHA-256 für die Signatur. |
Von Microsoft verwaltet, dies ist die Standardeinstellung; oder Kundenseitig verwaltet, eine Alternative zu von Microsoft verwalteten Schlüsseln. Organisationen, die über ein IT-verwaltetes Azure-Abonnement verfügen, können BYOK (Bring Your Own Key) verwenden und dessen Nutzung ohne zusätzliche Kosten protokollieren. Weitere Informationen finden Sie unter Implementieren von Bring Your Own Key. In dieser Konfiguration werden nCipher-Hardwaresicherheitsmodule (HSMs) verwendet, um Ihre Schlüssel zu schützen. |
Ja | |
S/MIME | Exchange | Kryptografische Nachrichtensyntax Standard 1.5 (Public Key Cryptography Standard (PKCS) #7) | Hängt von der vom Kunden verwalteten Public Key-Infrastruktur ab, die bereitgestellt wird. Der Kunde verwaltet die Schlüssel, und Microsoft hat nie Zugriff auf die privaten Schlüssel, die zum Signieren und Entschlüsseln verwendet werden. | Ja, wenn für die Verschlüsselung ausgehender Nachrichten mit 3DES oder AES256 konfiguriert ist |
Microsoft Purview-Nachrichtenverschlüsselung | Exchange | Identisch mit Azure RMS (Kryptografiemodus 2 – RSA 2048 für Signatur und Verschlüsselung und SHA-256 für Signatur) | Verwendet Azure Information Protection als Verschlüsselungsinfrastruktur. Die verwendete Verschlüsselungsmethode hängt davon ab, woher Sie die RMS-Schlüssel zum Verschlüsseln und Entschlüsseln von Nachrichten erhalten. | Ja |
SMTP-TLS mit Partner-organization | Exchange | TLS 1.2 mit AES 256 | Das TLS-Zertifikat für Exchange (outlook.office.com) ist ein 2048-Bit-SHA-256 mit RSA-Verschlüsselungszertifikat, das von DigiCert Cloud Services CA-1 ausgestellt wurde. Das TLS-Stammzertifikat für Exchange ist ein 2048-Bit-SHA-1 mit RSA-Verschlüsselungszertifikat, das von der GlobalSign-Stammzertifizierungsstelle R1 ausgestellt wurde. Aus Sicherheitsgründen ändern sich unsere Zertifikate von Zeit zu Zeit. |
Ja, wenn TLS 1.2 mit 256-Bit-Verschlüsselungsstärke verwendet wird |
*TLS-Zertifikate, auf die in dieser Tabelle verwiesen wird, gelten für US-Rechenzentren; Rechenzentren außerhalb der USA verwenden auch 2048-Bit-SHA256RSA-Zertifikate.
Verschlüsselungstechnologien, die in Communityumgebungen der Government-Cloud verfügbar sind
Verschlüsselungstechnologie | Implementiert von | Schlüsselaustauschalgorithmus und -stärke | Schlüsselverwaltung* | FIPS 140-2 überprüft |
---|---|---|---|---|
BitLocker | Exchange | AES 256-Bit | Der externe AES-Schlüssel wird in einem Geheimnissafe und in der Registrierung des Exchange-Servers gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja |
SharePoint | AES 256-Bit | Externer AES-Schlüssel wird in einem Geheimnissafe gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja | |
Skype for Business | AES 256-Bit | Externer AES-Schlüssel wird in einem Geheimnissafe gespeichert. Der Geheimnis-Safe ist ein gesichertes Repository, das allgemeine Rechteerweiterungen und Genehmigungen für den Zugriff erfordert. Der Zugriff kann nur mithilfe eines internen Tools namens Lockbox angefordert und genehmigt werden. Der externe AES-Schlüssel wird auch im Trusted Platform Module auf dem Server gespeichert. Ein 48-stelliges numerisches Kennwort wird in Active Directory gespeichert und durch Lockbox geschützt. | Ja | |
Dienstverschlüsselung | SharePoint | AES 256-Bit | Die Schlüssel, die zum Verschlüsseln der Blobs verwendet werden, werden in der SharePoint-Inhaltsdatenbank gespeichert. Die SharePoint-Inhaltsdatenbanken werden durch Datenbankzugriffssteuerungen und Verschlüsselung ruhender Daten geschützt. Die Verschlüsselung erfolgt mithilfe von TDE in Azure SQL-Datenbank. Diese Geheimnisse befinden sich auf der Dienstebene für SharePoint, nicht auf Mandantenebene. Diese Geheimnisse (manchmal auch als master Schlüssel bezeichnet) werden in einem separaten sicheren Repository gespeichert, das als Schlüsselspeicher bezeichnet wird. TDE bietet Sicherheit im Ruhezustand sowohl für die aktive Datenbank als auch für die Datenbanksicherungen und Transaktionsprotokolle. Wenn Kunden den optionalen Schlüssel angeben, wird der Kundenschlüssel in Azure Key Vault gespeichert. Der Dienst verwendet den Schlüssel zum Verschlüsseln eines Mandantenschlüssels, der zum Verschlüsseln eines Standortschlüssels verwendet wird, der dann zum Verschlüsseln der Schlüssel auf Dateiebene verwendet wird. Im Wesentlichen wird eine neue Schlüsselhierarchie eingeführt, wenn der Kunde einen Schlüssel bereitstellt. | Ja |
Skype for Business | AES 256-Bit | Jedes Datenstück wird mit einem anderen zufällig generierten 256-Bit-Schlüssel verschlüsselt. Der Verschlüsselungsschlüssel wird in einer entsprechenden XML-Metadatendatei gespeichert. Eine konferenzspezifische master Schlüssel verschlüsselt diese XML-Datei. Der master Schlüssel wird auch einmal pro Konferenz nach dem Zufallsprinzip generiert. | Ja | |
Exchange | AES 256-Bit | Jedes Postfach wird mit einer Datenverschlüsselungsrichtlinie verschlüsselt, die von Microsoft oder dem Kunden (bei Verwendung des Kundenschlüssels) kontrollierte Verschlüsselungsschlüssel verwendet. | Ja | |
TLS zwischen Microsoft 365 und Clients/Partnern | Exchange | Opportunistisches TLS, das mehrere Verschlüsselungssammlungen unterstützt | Das TLS-Zertifikat für Exchange (outlook.office.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für Exchange ist ein 2048-Bit-SHA1RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja, wenn TLS 1.2 mit 256-Bit-Verschlüsselungsstärke verwendet wird |
SharePoint | TLS 1.2 mit AES 256 | Das TLS-Zertifikat für SharePoint (*.sharepoint.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für SharePoint ist ein 2048-Bit-SHA1RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja | |
Microsoft Teams | Häufig gestellte Fragen zu Microsoft Teams – Admin Hilfe | Das TLS-Zertifikat für Microsoft Teams (teams.microsoft.com; edge.skype.com) ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. Das TLS-Stammzertifikat für Microsoft Teams ist ein 2048-Bit-SHA256RSA-Zertifikat, das von Baltimore CyberTrust Root ausgestellt wurde. |
Ja | |
TLS zwischen Microsoft-Rechenzentren | Exchange, SharePoint, Skype for Business | TLS 1.2 mit AES 256 | Microsoft verwendet eine intern verwaltete und bereitgestellte Zertifizierungsstelle für die Server-zu-Server-Kommunikation zwischen Microsoft-Rechenzentren. | Ja |
Secure Real-Time Transport Protocol (SRTP) | ||||
Azure Rights Management Service | Exchange | Unterstützt kryptografischen Modus 2, eine aktualisierte und erweiterte RMS-Kryptografieimplementierung. Es unterstützt RSA 2048 für Signatur und Verschlüsselung und SHA-256 für Hash in der Signatur. | Verwaltet von Microsoft. | Ja |
SharePoint | Unterstützt kryptografischen Modus 2, eine aktualisierte und erweiterte RMS-Kryptografieimplementierung. Es unterstützt RSA 2048 für Signatur und Verschlüsselung und SHA-256 für Hash in der Signatur. |
Von Microsoft verwaltet, dies ist die Standardeinstellung; oder Vom Kunden verwaltete Schlüssel (auch als BYOK bezeichnet), eine Alternative zu von Microsoft verwalteten Schlüsseln. Organisationen, die über ein IT-verwaltetes Azure-Abonnement verfügen, können BYOK verwenden und dessen Nutzung ohne zusätzliche Kosten protokollieren. Weitere Informationen finden Sie unter Implementieren von Bring Your Own Key. Im BYOK-Szenario werden nCipher-HSMs verwendet, um Ihre Schlüssel zu schützen. |
Ja | |
S/MIME | Exchange | Syntax für kryptografische Nachrichten Standard 1.5 (PKCS #7) | Hängt von der bereitgestellten Public Key-Infrastruktur ab. | Ja, wenn für die Verschlüsselung ausgehender Nachrichten mit 3DES oder AES-256 konfiguriert ist. |
Office 365-Nachrichtenverschlüsselung | Exchange | Identisch mit Azure RMS (Kryptografiemodus 2 – RSA 2048 für Signatur und Verschlüsselung und SHA-256 für Hash in der Signatur) | Verwendet Azure RMS als Verschlüsselungsinfrastruktur. Die verwendete Verschlüsselungsmethode hängt davon ab, woher Sie die RMS-Schlüssel zum Verschlüsseln und Entschlüsseln von Nachrichten erhalten. Wenn Sie Azure RMS zum Abrufen der Schlüssel verwenden, wird der Kryptografiemodus 2 verwendet. Wenn Sie Active Directory (AD) RMS verwenden, um die Schlüssel abzurufen, wird entweder Kryptografiemodus 1 oder 2 verwendet. Die verwendete Methode hängt von Ihrer lokalen AD RMS-Bereitstellung ab. Kryptografiemodus 1 ist die ursprüngliche Kryptografieimplementierung für AD RMS. Es unterstützt RSA 1024 für Signatur und Verschlüsselung und SHA-1 für die Signatur. Alle aktuellen Versionen von RMS unterstützen diesen Modus, mit Ausnahme von BYOK-Konfigurationen, die HSMs verwenden. |
Ja |
SMTP-TLS mit Partner-organization | Exchange | TLS 1.2 mit AES 256 | Das TLS-Zertifikat für Exchange (outlook.office.com) ist ein 2048-Bit-SHA-256 mit RSA-Verschlüsselungszertifikat, das von DigiCert Cloud Services CA-1 ausgestellt wurde. Das TLS-Stammzertifikat für Exchange ist ein 2048-Bit-SHA-1 mit RSA-Verschlüsselungszertifikat, das von der GlobalSign-Stammzertifizierungsstelle R1 ausgestellt wurde. Aus Sicherheitsgründen ändern sich unsere Zertifikate von Zeit zu Zeit. |
Ja, wenn TLS 1.2 mit 256-Bit-Verschlüsselungsstärke verwendet wird. |
*TLS-Zertifikate, auf die in dieser Tabelle verwiesen wird, gelten für US-Rechenzentren; Rechenzentren außerhalb der USA verwenden auch 2048-Bit-SHA256RSA-Zertifikate.