Wird mein Arbeitsplatz als IT-Administrator noch benötigt, wenn mein Arbeitsgeber die IT-Infrastruktur in die Cloud verlagert?
Mit dieser Frage beschäftigen sich viele IT-Administratoren, sobald der Arbeitgeber das strategische Ziel "Wir migrieren in die Cloud" ausgerufen hat. Der technologische Enthusiasmus beim Thema Cloud-Technologien lässt oft keinen Raum für die aufkommenden Ängste der Angestellten.
Einer der regelmäßig angeführten Gründe für eine Einführung von Cloud-Technologien in Unternehmen ist die Möglichkeit, die Anzahl der IT-Mitarbeiter zu reduzieren. Durch die Abschaffung der lokalen IT-Infrastruktur würde automatisch weniger Personal für den laufenden Betrieb benötigt.
Hier verspüren IT-Mitarbeiter schnell eine Ohnmacht in ihrer beruflichen Situation, da die Entscheidung für einen Wechsel zu Cloud-Technologien meist nicht begründet wird und die persönlichen Vorurteile gegen die Cloud negative Empfindungen fördern.
Diese Ohnmacht ist jedoch unbegründet.
Ich möchte das Gefühl der Ohnmacht in der persönlichen beruflichen Situation nicht verharmlosen. Aber es gibt keinen Grund, sich dieser Ohnmacht einfach zu ergeben.
Die Einführung von Cloud-Technologien ist weder von Grund auf etwas Böses, noch ist es das einzig Heilbringende für die IT-Infrastruktur eines Unternehmens. Cloud-Technologien bieten aber neue Möglichkeiten und damit wesentlich flexiblere Betriebsszenarien, als sie mit einer lokalen und statischen IT-Infrastruktur möglich sind. Man darf auch nicht vergessen, dass Cloud nicht automatisch bedeutet, dass IT-Komponenten und Daten bei Drittdienstleistern verarbeitet werden. Die Flexibilität der Cloud-Technologien kann ich auch als private Cloud in meiner eigenen IT-Infrastruktur betreiben.
Und hier kommen Sie als IT-Mitarbeiter ins Spiel. Ihr Arbeitgeber ist darauf angewiesen, dass Sie sich dem Thema Cloud annehmen, Cloud-Technologien kennenlernen und zu bedienen wissen. Sie müssen in der Lage sein, die von externen Beratern erstellten Cloud-Konzepte bewerten zu können. Dies gilt nicht nur für den klassischen IT-Administrator, sondern ebenso für Datenbank- und Applikationsadministratoren.
Die technologischen Möglichkeiten, Daten zu speichern, Applikationen zu betreiben und Dienste bereitzustellen, ändern sich stetig. Damit geht automatisch ein stetiges Lernen für die Planung und Nutzung dieser Technologien einher. In der klassischen IT erfolgten Softwareänderungen oft nur in einem 2-Jahres Rhythmus durch die Einspielung von Service Packs. Clouddienste erfreuen uns mit Neuerungen, Änderungen, aber auch Streichungen von Funktionen in einem wöchentlichen Rhythmus. Und dies ist ganz unabhängig davon, ob es sich um Software-as-a-Service, Platform-as-a-Service oder Infrastructure-as-a-Service handelt.
Diese Veränderungen und insbesondere die Veränderungsgeschwindigkeit schüren verständlicherweise die Angst um den Verlust des eigenen Arbeitsplatzes.
Wie sieht die Zukunft für Administratoren in der IT aus?
Es gibt keinen Grund, dass die Veränderungen bei der Einführung und Nutzung von Cloud-Technologien Ihnen Angst machen. Der für das Unternehmen passende und sichere Betrieb von Cloud-Technologien benötigt gut ausgebildetes Personal. Sie verfügen gegenüber externen Cloud-Beratern über einen ganz entscheidenden Vorteil, Sie kennen die Bedürfnisse und Anforderungen der Mitarbeiter und des Unternehmens. Sie haben die Chance, die Einführung und den Betrieb von Cloud-Technologien in Ihrem Unternehmen mitzugestalten. Finden Sie Ihren persönlichen Themenschwerpunkt in den zahlreichen Cloud-Technologien und etablieren Sie sich so als Experte in Ihrer IT-Abteilung.
“Be passionate and bold. Always keep learning. You stop doing useful things if you don't learn.” – Satya Nadella, CEO, Microsoft
Im Idealfall ist Ihr Beruf nicht nur Beruf, sondern sogar Berufung. Die tägliche Arbeit soll Spaß machen. Wenn Sie das Gefühl haben, dass sich Ihr Arbeitgeber und damit Ihr Arbeitsplatz nicht den modernen Anforderungen anpasst und technische Veränderung nicht stattfindet, dann habe ich nur einen Rat für Sie: Wechseln Sie den Arbeitgeber. Insbesondere dann, wenn er Ihre persönliche Weiterbildung ausdrücklich nicht fördern möchte.
Bringen Sie Ihr IT-Wissen auf Stand und nutzen Sie das Internet, um Veränderung zu gestalten. Die folgenden Quellen sind nur als Einstieg aufgeführt. Viele der Angebote sind kostenfrei.
Haben Sie Mut zur Veränderung. Das Erlernen neuer Technologien ist bei weitem nicht so schwer, wie man es sich gemeinhin vorstellt. Und wenn Sie neues Wissen erlangt haben, haben Sie auch den Mut, sich zertifizieren zu lassen.
Als erstes Zertifizierungsziel empfehle ich Ihnen die Zertifizierung zum MCSA: Office 365.
Es ist vollkommen normal, dass Sie ein Gefühl der Ohnmacht erfasst, wenn sich große Veränderungen, wie die Einführung von Cloud-Technologien, an Ihrem IT-Arbeitsplatz ankündigen. Es gibt aber keinen Grund, in diesem Gefühl zu erstarren. Sehen Sie es als Chance für Ihre berufliche Weiterentwicklung.
Nutzen Sie die zahlreichen kostenfreien und auch kostenpflichtigen Angebote zum Erlernen der unterschiedlichen Cloud-Technologien. Finden Sie Ihr thematisches Fachgebiet und etablieren Sie sich hier als Experte für Ihre IT-Abteilung. Ihr Arbeitgeber ist auf fachlich qualifizierte Mitarbeiter angewiesen. Haben Sie Mut zur beruflichen Veränderung.
Cloud ist kein Ort - Cloud ist ein Gedanke
Die Themen E-Mail Verschlüsselung und E-Mail Sicherheit sind keine neue Themen. Die vergangenen Veröffentlichungen im Rahmen der Whistleblower-Affären haben dazu geführt, dass die breite Masse sich mit dem E-Mail Sicherheit beschäftigt. Verschlüsselung an sich ist ein komplexes Thema und dies scheint einer der Gründe dafür zu sein, warum es nach einem ersten Aufschrei wieder in der Versenkung verschwindunden ist.
Große deutsche Anbieter haben die Aufregung der ersten Stunde dazu genutzt, eine geschickte Marketing Kampagne zu starten (Stichwort: "E-Mail Made in Germany"), um von ihren Sicherheitsverfehlungen in der Vergangenheit abzulenken. Man darf die Augen nicht davor verschließen, dass die "großen Provider" vor Edward Snowden die Verschlüsselung des E-Mail Übertragungskanals aus Kosten- und Effizienzgründen nicht konfiguriert haben.
Die Verwendung von sichereren Übertragungskanälen ist weder eine Erfindung der Neuzeit und schon gar nicht eine Erfindung der Telekommunikationsanbieter. Die entsprechende Softwareprogramme unterstützten diese Funktionen schon vorher, da das notwendige Protokoll bereits 1999 (RFC 2487) eingeführt wurde. Die von WEB.DE in diesem Artikel verwendete Grafik suggeriert im Kontext des Artikels, dass nur GMX, WEB.DE und T-ONLINE über eine sichere Kommunikation verfügen und andere Anbieter dies nicht gewährleisten. Das ist schlichtweg falsch.
Technologisch besteht keinerlei Notwendigkeit, sich auf große Provider zu verlassen, wenn es um das Thema E-Mail Sicherheit geht. Selbst bei Anwendung des deutschen Datenschutzgesetzes, sind Daten des Kunden auf Geräten des Providers und sind damit rechtlich dem Zugriff des Kunden entzogen.
Aber was kann ich als Unternehmen machen, um E-Mails sicher zu übertragen und die Integrität der E-Mails sicherzustellen?
Der Schutzbedarf der E-Mail Kommunikation stellt sich für jedes Unternehmen anders dar.
Mögliche Fragen sind:
Das Thema E-Mail Verschlüsselung und E-Mail Sicherheit ist und bleibt komplex. Jedoch können Sie mit Hilfe kompetenter Berater die passende Lösung finden und die Sicherheit und Integrität Ihrer E-Mails sicherstellen.
Grundsätzlich und faktisch basiert E-Mail Sicherheit auf Vertrauen. Das Vertrauen ist begründet sich technisch in den Vertrauensstellungen der verwendeten und gültigen Zertifikate auf der einen Seite und den organisatorischen und vertraglichen Vertrauensstellungen zwischen Kunden und Software- bzw. Dienstanbietern auf der anderen Seite.
Die technischen Aspekte der E-Mail Sicherheit werden im Rahmen von drei weiteren Blog Artikel auf http://blog.granikos.eu behandelt.
Die Themen der Serie sind:
Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.
Im ersten Blog-Artikel dieser Miniserie wurde allgemein das Thema E-Mail Verschlüsselung und E-Mail Sicherheit besprochen. In diesem Artikel wird die Verschlüsselung des Übertragungsweges mit TLS genauer betrachtet.
E-Mail Sicherheit besteht nicht nur aus der Sicherung des Übertragungsweges zwischen den beteiligten Systemen, sondern auch aus der optionalen Verschlüsselung bzw. Signierung der Nachricht selber. Die Verschlüsselung des Übertragungsweges ist aber die Grundvoraussetzung für eine sichere Kommunikation und seit 1999 Stand der Technik.
Bei der Sicherung des Übertragungsweges erfolgt zwischen zwei Servern mit Hilfe der Transport Layer Security (TLS). TLS ist das Nachfolgeprotokoll des Secure Socket Layer (SSL) Protokolls und wird gegenwärtig in der Version 1.2 eingesetzt. Hierbei handelt es sich um ein zertifikatsbasiertes Protokoll, das zur Sicherung von unterschiedlichen TCP Protokollen verwendet wird. Hierzu zählen u.a. POP3, IMAP, SIP, SMTP, HTTP oder LDAP.
Die grundsätzliche Implementierung des TLS Protokolls und aller Protokolleinstellungen ist Teil des Server-Betriebssystems (Windows Server) und nicht der verwendeten E-Mail Software. Ausgeführte Konfigurationen wirken sich somit auf alle Applikationen auf dem Server aus. Der vierte Blog-Artikel dieser Reihe beschreibt die Konfiguration und die Auswirkungen im detaillierter.
Bei der Verwendung von TLS ist nur die Kommunikation zwischen zwei Servern (Sender und Empfänger) verschlüsselt. In den jeweiligen Unternehmensnetzen ist es möglich, dass die Übertragung zwischen anderen beteiligten Systemen unverschlüsselt erfolgt. Von einer unverschlüsselten Kommunikation, also ohne Verwendung von TLS, ist auch innerhalb eines Unternehmensnetzwerkes dringend abzuraten.
Einfache Darstellung der TLS Kommunikation zwischen zwei E-Mail Systemen:
Diese einfache Darstellung lässt sich beliebig in seiner Komplexität erweitern. Im nachfolgenden Beispiel wird gezeigt, dass auf der Sender-Seite eine interne Lösung zur Anti-Malware Erkennung betrieben wird, während auf der Empfänger-Seite eine Cloud-basierte Lösung im Einsatz ist.
Im vorstehenden Beispiel können Sie als Sender nur die Verbindung zwischen der Anti-Malware Lösung und dem Cloud-Anbieter überwachen und prüfen. Den Status und die Konfiguration zwischen dem Services des Cloud-Anbieters und dem E-Mail Server des Empfänger können Sie nicht kontrollieren.
Auch wenn alle Verbindungen "TLS verwenden", so können die verwendeten Verschlüsselungsmechanismen (Cipher Suite, Hashes, Signature) für jede der TLS Verbindungen unterschiedlich sein. Somit ist auch jede der Verbindungen unterschiedlich "sicher".
In der Grundkonfiguration führt TLS nur Grundprüfungen der verwendeten Zertifikate durch. Hierzu gehört u.a., ob das Zertifikat zeitlich noch gültig ist. Eine Überprüfung, ob das Zertifikat vielleicht zwischenzeitlich zurückgezogen wurde und daher ungültig ist, gilt bereits als erweiterte Prüfung. Solch eine erweiterte Prüfung ist Aufgabe der eingesetzten E-Mail Software.
Das TLS Protokoll selber ist anfällig für Man-In-The-Middle Angriffe und wird daher als nicht 100% sicher eingestuft. Hintergrund ist, dass es zweifelhafte Zertifizierungsstellen gibt, die Zertifikate ohne genaue Prüfung herausgeben. Hierdurch können sich unberechtigte Dritte als jemand anderes ausgeben (siehe Linkliste). Das Risiko lässt sich nur dadurch minimieren, indem auf den eigenen Systemen die fragwürdige Zertifizierungsstellen deaktiviert werden.
Gerade die unterschiedlichen Konfigurationen der TLS Sicherheit führen im täglichen Betrieb immer wieder zu Problemen. Wenn ein Server mit einer "zu sicheren" Konfiguration betrieben wird, kann es zu "Verständigungsproblemen" mit einem Server auf der anderen Seite kommen. Ist der empfangende Verbindungsendpunkt nun so konfiguriert, dass TLS erforderlich ist, so kommt keine Verbindung Zustande und die Nachricht kann nicht zugestellt werden. Ist wiederum TLS als optional konfiguriert, so wird die Nachricht on TLS Verschlüsselung übertragen. Hieraus ergibt sich die Notwendigkeit, zwei unterschiedliche Endpunkte zu betreiben:
Interne Systeme - das unbekannte Risiko
Interne Applikationen und Systeme stellen ein großes Risiko dar, wenn sie nicht in der Lage sind, unternehmenskritische Kommunikation mit Hilfe von TLS Verschlüsselung zu einem internen E-Mail Server zu übertragen. Noch kritischer ist die Situation, wenn interne Applikationen oder Systeme direkt mit Systemen außerhalb des Unternehmensnetzwerkes kommunizieren und nicht über Verschlüsselungsfunktionen verfügen. Als beispielhafte interne Applikationen oder Systeme seien genannt:
Es wird deutlich, dass das Thema E-Mail Sicherheit nicht isoliert betrachtet werden kann, sondern vielmehr mit einer ganzheitlichen Betrachtung der gesamten IT-Landschaft einhergeht.
Ein Serversystem mit einer aktuellen E-Mail Software und aktiviertem TLS zu betreiben reicht nicht aus, um die E-Mail Sicherheit für ein Unternehmen zu gewährleisten. Neben den rein technischen Aspekten zur sicheren Konfiguration der TLS Implementierung müssen auch organisatorische Aspekte zur Kommunikation mit Partnerunternehmen geklärt und festgeschrieben werden.
Technik ist ein Hilfsmittel zur Sicherstellung der Sicherheit. Sie befreit nicht von einer sorgsamen Planung und Dokumentation (auch zur Auditzwecken) der E-Mail Umgebung.
Um die Sicherheit der Kommunikation zu Erhöhen, können Nachrichten nicht nur sicher übertragen, sondern digital signiert und/oder verschlüsselt werden. Hierzu stehen die Technologien S/MIME oder PGP zur Verfügung. Im nächsten Blog-Artikel befassen wir uns mit diesen beiden Technologien.
Exchange Server ist ein sehr tolerantes Produkt und lässt sich in unterschiedlichste IT-Infrastruktur-Varianten installieren. Einige der möglichen Infrastruktur-Varianten sind gut geeignet für den Betrieb von Exchange Server, andere leider weniger gut. Daher ist es immens wichtig, bei der Planung einer Exchange Server Umgebung die notwendige Sorgfalt walten zu lassen.
Basis für die Planung einer Exchange Server Implementierung ist der Hauptgrundsatz für moderne Exchange Server Versionen:
Dieser Hauptgrundsatz wird, wie die Erfahunrg zeigt, leider allzu häufig ignoriert. Dieser Ignoranz wird in vielen Fällen dadurch Vorschub geleistet, dass Hard- und Software-Hersteller ihre ganz eigenen Hochverfügbarkeitslösung (HA) verkaufen möchten. Zu diesen Lösungen gehören sowohl HA-Funktionen von Hypervisor-Plattformen, aber auch, und dies viel häufiger, HA-Lösungsansätze von Storageanbietern.
Die Standardisierung einer Plattform wird nicht dadurch erreicht, indem eine unnötig komplexe Infrastruktur zum Standard erklärt wird, sondern das eine möglichst einfache Implementierung der Exchange Server Plattform zum Standard gemacht wird.
Unzählige Supportanfragen bei der Exchange Produktgruppe (PG) haben die Preferred Architecture Empfehlung über die Jahre reifen lassen. Sie ist daher keine spontan entstandene Empfehlung. Sie ist entstanden aus den Anforderungen und Kenntnisgewinnen im täglichen Betrieb der hochverfügbaren Cloudinfrastruktur von Exchange Online.
Sicherlich werden Sie nun einwenden, dass Sie keine Cloud-Plattform betreiben möchten. Sie dürfen nicht vergessen, dass eine moderne Exchange Server Version hochverfügbar betrieben werden möchte. Vergessen Sie daher nicht den Hauptgrundsatz für moderne Exchange Server Versionen ab Version 2013.
Auf der Microsoft Ignite Konferenz 2017 wurde in zahlreichen Vorträgen auf die Preferred Architecture Bezug genommen. Man konnte dem Eindruck erliegen, dass hier missioniert werden sollte. Am letzten Tag der Konferenz haben Boris Lokhvitsky und Robert Gillies eine sehr interessante Session zur richtigen Implementierung von Exchange Server gehalten. Hierbei wurde auch betrachtet, welche technischen Mindestanforderungen für eine Exchange Server Implementierung gelten und wie eine optimale Betriebsumgebung aussieht. Ein optimaler Betrieb einer On-Premises Implementierung folgt der Preferred Architecture. Ist dies nicht möglich sollte man sich für einen Wechsel zu Exchange Online entscheiden.
Das nachfolgende Diagramm verdeutlicht die unterschiedlichen Design-Optionen für eine Messaging-Plattform auf Basis von Exchange Server 2016.
Was bedeutet das nun im Detail für eine erfolgreiche Exchange Server Implementierung?
Was ist nun die viel zitierte Preferred Architecture und was bedeutet sie für eine erfolgreiche On-Premises Implementierung und den sicheren Betrieb von Exchange Server.
Die Preferred Architecture ist kein starres Gebilde. Vielmehr passt sie sich regelmäßig den technischen Gegebenheiten an. Zuletzt wurde z.B. die Empfehlung für den maximalen Arbeitsspeicher je Server von 96GB auf 192GB angehoben.
Nachfolgend werden die vier Bereiche der Preferred Architecture beschrieben. Ich empfehle aber dringend, immer auf den aktualisierten EHLO Blog Artikel Bezug zu nehmen und sich noch einmal mit der Exchange Server 2016 Architektur vertraut zu machen.
Die Preferred Architecture gliedert sich in die folgenden vier Bereiche:
Der Exchange Namensraum (Namespace) beschreibt die DNS Hostnamen, die erforderlich sind, damit sich Clients (z.B. Outlook, Browser oder mobile Endgeräte) mit den Exchange Servern verbinden können. Im Rahmen des Data Center Designs (s.u.) wird davon ausgegangen, dass diese Verbindungen auf zwei Standorte verteilt werden.
Bei der Planung der Exchange Server Namensräume (Namespaces) unterscheidet man zwischen gebundenen (bound) und ungebundenen (unbound) Namensräumen für Exchange Server in zwei Rechenzentren.
Bei einem gebundenen Namensraum besitzt jedes Rechenzentrum einen eindeutigen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen erfolgen somit immer zu dem Rechenzentrum, in dem sich auch die aktive Datenbankkopie des angefragten Benutzerpostfaches befindet.
Bei einem ungebunden Namensraum verfügen die Rechenzentren über keine eigenen Namen für den Zugriff auf Exchange Server Client Access Services. Clientverbindungen werden bei jeder Anfrage durch den Load Balancer in eines der beiden Rechenzentren geleitet. Eine Ausnahme bilden hier die Office Online Server (OOS), die immer einen gebundenen Namensraum erfordern.
Das nachfolgende Beispiel für eine Preferred Architecture Namespace Design benötigt vier Namen:
Eine hochverfügbare und ausfallsichere Architektur erfordert den Betrieb von mindestens zwei Rechenzentren. Ob es sich nun um vollwertige und eigenständige Rechenzentren oder um lokale Serverräume in getrennten Brandabschnitte im gleichen Gebäude handelt, lasse ich hier bewusst offen. Die Anforderungen zur Verfügbarkeit von IT-Basisdiensten hängen schließlich nicht nur von einer Exchange Server Implementierung ab.
Eine wichtige Anforderung ergibt sich aber für den Betrieb des Active Directory in der Preferred Architecture.
Der über zwei Rechenzentren gestreckte Betrieb einer einzelnen Active Directory Site wird zwar technisch unterstützt, für die Preferred Architecture ist es aber empfohlen, dass jedes Rechenzentrum in einer eigenen Active Directory Site abgebildet wird. Die Gründe dafür sind:
In der Preferred Architecture werden alle Exchange Server mit Postfachrolle als physikalische Systeme betrieben. Die Hauptgründe hierfür sind:
Die physikalischen Server, die für eine Preferred Architecture Implementierung verwendet werden, haben keine allzu besonderen Anforderungen. Solch ein Standard-Server besteht aus:
Die weiteren Konfigurationen des Servers sind:
Um eine optimale Nutzung der Systemressourcen im ungebundenen Namensraummodell zu gewährleisten, werden die aktiven Kopien der Datenbanken gleichmäßig (symmetrisch) über alle Mitgliedsserver der Database Availability Group (DAG) verteilt. Die maximal 16 Mitgliedsserver einer DAG werden ebenfalls symmetrisch, mit einer geraden Anzahl an Servern je Rechenzentrum über alle Rechenzentren verteilt.
Durch mehr Mitgliedsservern in einer DAG wird eine bessere Redundanz und Nutzung der Ressourcen sichergestellt. Die Preferred Architecture sieht vor, dass eine DAG aus mindestens acht Mitgliedsservern besteht. Bei einem steigenden Ressourcenbedarf wird die DAG um weitere Mitgliedsserver erweitert.
In der Preferred Architecture benötigt Exchange Server für einen sicheren Betrieb nur eine einzelne Netzwerkschnittstelle. Diese Netzwerkschnittstelle wird ohne Teaming betrieben. Diese vereinfachte Netzwerkanforderung erleichtert den Betrieb und auch die Wiederherstellung im absoluten Fehlerfall. Eine separate Heartbeat-Netzwerkschnittstelle für die Cluster-Kommunikation ist nicht erforderlich.
Der Witness Server einer DAG gewährleistet das korrekte Verhalten der DAG bei einem automatischen Failover, sollte es zu einem Ausfall eines Rechenzentrums kommen. Im Idealfall wird der Witness Server an einem dritten Standort in einer anderen Active Directory Site platziert. Sollte kein dritter Standort zur Verfügung stehen, so kann der Witness Server auch in Microsoft Azure betrieben werden.
Was ist nun die richtige Exchange Server Architektur?
Wenn Sie der Preferred Architecture (Blauer Kreis) oder aber der Best Practice Empfehlung (Lila Kreis) folgen, können Sie einen sicheren Betrieb der E-Mail Plattform in Ihrem Unternehmen gewährleisten, ohne unnötige technische Risiken einzugehen. Jenseits einer Nutzung von Exchange Online stellen diesen beiden Design-Optionen das Optimum für einen zuverlässigen Betrieb dar. Je weiter Sie sich von der Preferred Architecture für Exchange Server entfernen, um so mehr steigt das Betriebsrisiko.
Wenn Sie den vollmundigen Produktversprechen von Drittherstellern für Speicherlösungen oder anderen faszinierenden Lösungen zur Hochverfügbarkeit von Exchange Server folgen, so verabschieden SIe sich in eine individuelle "funktioniert irgendwie" Implementierung. Tritt bei solch einer Implementierung ein Fehlerfall auf, so liegt das Problem nicht beim Produkt Exchange Server. Die Erfahrung hat leider gezeigt, dass in solchen Fällen immer von Unzulänglichkeiten in der Implementierung abgelenkt wird.
Als absolute Mindestempfehlung gilt eine Exchange Server Implementierung, die den Exchange Server Systemanforderungen und den Exchange Server Speicherkonfigurationsoptionen folgt.
Abkürzungen
Viel Spaß beim Betrieb von Exchange Server.
"Zu wissen, was man weiß, und zu wissen, was man tut, das ist Wissen."
Seit den Zeiten von Konfuzius ist dies eine der Maximen über Wissen an sich und hat auch seine ganz eigene Bedeutung in der heutigen IT und dem strategischen Betrieb von komplexen und sicheren IT-Umgebungen.
Die größte Gefahr in jeder IT-Umgebung ist somit das Unwissen. Nach der Identifikation eines Problems und dem Finden der Ursache, verbleibt nur das Auffinden von technischen Ressourcen, um das Problem zu beseitigen. Um das zu erreichen und um die organisatorischen Geschäftsanforderungen voranzutreiben, benötigen Unternehmen eine intelligente Sicht auf das große Ganze. Oder ganz einfach: Enterprise IT ist auf solide Berichterstattung angewiesen.
Es gibt im IT-Portfolio eines Unternehmens keine Dienstleitung, die ähnlich wichtig ist, wie E-Mail (ergänzt durch Exchange und Active Directory Datenbanken). Für die meisten Unternehmen ist E-Mail die wichtigste Kommunikationsart und damit die Lebensader für einen erfolgreichen Betrieb. Leider übersehen viele IT-Verantwortliche wichtige E-Mail bezogene Themen, die sich auf die Produktivität, betriebliche Effizienz und letztlich auf die Rentabilität des Unternehmens auswirken. Zahlreiche Herausforderungen, wie Ausfälle und Service-Optimierungen, Sicherheitswarnungen und Speicherengpässe, wirken sich in ganzer Linie auf den Betrieb des Unternehmens aus. Ohne messbare KPIs für solch kritische Applikationen versuchen Unternehmen eine große Unbekannte zu verwalten. Sie fliegen sozusagen blind.
Im Fall von Exchange muss eine Berichterstattung drei Themenbereiche abdecken, um einen produktiven und effizienten Betrieb zu unterstützen:
Eine Berichterstattung über Exchange ist kein monolithisches Gebilde, vielmehr erfordert eine produktive Berichterstattung unterschiedliche Detailierungsebenen, um alle notwendigen Informationen für schnellere und bessere Entscheidungen bereitzustellen. Zum Beispiel ist für einen CIO nicht von Vorteil, wenn er Kenntnis darüber hat, dass ein bestimmter Benutzer das Postfachlimit überschritten hat. Diese Information ist für Service-Desk Mitarbeiter viel sinnvoller. Die generelle Information aber, wie viele Nutzer das Limit überschritten haben, hilft bei der strategischen Planung und Budget-Entscheidungen für die IT-Infrastruktur.
Mit Hilfe einer Rollen-basierten Berichterstellung erhalten die Mitglieder einer Rolle genau die Informationen, die sie für Ihre speziellen Aufgaben benötigen. Dies vereinfacht zum einen die Arbeit der Mitarbeiter selber und stellt zum anderen sicher, dass keine unnötigen oder unerlaubten Daten im Zugriff sind.
Ein weiteres Problem heutiger Berichterstattung in der IT ist, dass zahlreiche Berichte automatisch erstellt und per E-Mail an unterschiedliche Empfänger zugestellt werden. Dort werden sie meist durch Postfachregeln automatisch in Unterordner sortiert und harren dort aus, um gelesen zu werden. Die Informationen sind zum Zeitpunkt des Lesens bereits wieder veraltet und stellen nur einen alten, bereits vergangenen, Betriebszustand dar, und nicht den aktuellen Betriebszustand.
Jenseits dieser eher abstrakten Darstellungen folgen nun zwei reelle Anwendungsbeispiele:
Was ist mit der Identifizierung fragwürdiger Aktivitäten?
Exchange Auswertungen helfen dem Service-Desk Mitarbeiter fragwürdige IP-Adressen zu identifizieren, die auf Nutzerpostfächer zugreifen, und dies auf eine Block-Liste zu setzen. Exchange Administratoren können abgelaufene und ungenutzte Benutzerkonten (eine Spielwiese für Malware und Sicherheitsbrüche) identifizieren und deaktivieren oder löschen. Die HR Abteilung kann nachverfolgen, ob bestimmte Benutzer gegen Unternehmensrichtlinien verstoßen. Und der CIO kann sicherstellen, dass alle Sicherheitsinitiativen den rechtlichen Vorschriften entsprechen.
Wie hilft das Wissen über die Speicherkapazitäten bei der Umsatzgenerierung des Unternehmes?
Stellen Sie sich vor, Ihr Verkaufsteam kann eine wichtige Verkaufspräsentation oder eine wichtiges und vertrauliches Angebot nicht zum Kunden senden, da das Postfachlimit des Teams erreicht ist. In dem Fall erfolgt sicher eine umgehende interne Eskalation, die durch ein pro-aktive Überwachung und Berichterstattung vermeidbar gewesen wäre. Solche Situationen sind für alle Beteiligten nervenaufreibend und unnötig. Mit dem Wissen über die aktuellen Speicherkapazitäten und -limits kann schon im Vorfeld solcher Situationen eingegriffen werden und das Verkaufsteam bleibt produktiv.
Nachfolgend wird anhand von Anwendungsbeispielen gezeigt, die personalisierte Berichterstattung helfen kann:
Erkennung, Blockierung, Quarantäne von E-Mails aus fragwürdigen Quellen
Nutzungs- und Zugriffkontrolle (z.B. BYOD) und Einhaltung von Unternehmensrichtlinien Unterscheidung zwischen rechtmäßiger Unternehmensnutzung und missbräuchlicher Nutzung durch Anwender
Überwachung von ungewöhnlichen Nutzeraktivitäten, wie z.B. unberechtigter Zugriff auf Postfächer der Unternehmensleitung
Reduzierung von Sicherheitslücken durch Löschung von alten oder ungenutzten Benutzerkonten
Identifikation von möglichen Sicherheitsrisiken und damit Hilfe beim Schutz geistigen Eigentums
Durchsetzung von Richtlinien mit Hilfe von Active Directory Einstellungen
Sicherstellung des IT-Betriebes im Rahmen der Compliance
Ausarbeitung von Zugriffs- und Sicherheitsrichtlinien, basierend auf aktueller Exchange-Auslastung
Benachrichtigung von Anwendern, vor dem Erreichen des Postfachlimits
Löschen von inaktiven Postfächern, um CALs und Speicherplatz besser auszunutzen
Identifikation von anormal anwachsenden E-Mail-Warteschlangen, bevor größere Probleme entstehen
Troubleshooting und Diagnose
Erkennung von Nutzungsmuster, die sich negativ auf den laufenden Betrieb auswirken können (z.B. Nutzungsspitzen) oder die generelle Performance beeinträchtigen
Genehmigung notwendiger Ressourcen, um die Produktivität sicherzustellen Auditierung und Kontrolle des Lifecycle Managements der Hardware
Hilfe bei der Entwicklung von Standards und Nutzerrichtlinien
Reaktion auf kritische Betriebszustände (Plattenplatz, Prozessor- und Speicherauslastung), um Störungen des laufenden Betriebs zu vermeiden
Erleichterung der Betriebsplanung, Ausführung von Archivierungsrichtlinien und die Verfeinerung von Backup Prozessen
Verständnis der Ressourcennutzung und die Abhängigkeit zwischen Nutzungsverhalten und Produktivität
Einhaltung von Service Level Agreements
Kenntnis über die Speichernutzung und Planung von notwendigen Erweiterungen
Kenntnis über das Service-Desk Last-Aufkommen
Verwaltung der Speicherkapazitäten, Serverressourcen und anderer zugehöriger Kosten
Detailliertes Verständnis der Kosten- und Nutzungsstrukturen
Begründung von Budgetanforderungen für notwendigen Erweiterungen durch Chargeback-Berichte für jede Abteilung
Die meiste Unternehmen haben nur eine begrenzte Anzahl an Mitarbeitern zur Verfügung, die sich um mit dem stetigen Wandel der IT-Anforderungen mitzuhalten. Die Menge an E-Mail Datenverkehr und die Postfachgrößen selber werden weiter wachsen. Berichtssysteme selber werden dieses Probleme nicht lösen, sie helfen aber, die notwendigen aktuellen Informationen den richtigen Personen zum richtigen Zeitpunkt zur Verfügung zu stellen.
Mit den richtigen Informationen können Sie neue Anschaffungen für den sicheren Betrieb Ihrer Exchange Infrastruktur auch detailliert begründen.
Möchten Sie mehr darüber erfahren, wie Mailscape Ihnen dabei helfen kann die Lücken über das Wissen in Ihrer Umgebung zu schließen?
http://www.granikos.eu/de/Mailscape
In der heutigen Zeit ist die skriptbasierte Verwaltung von Server-Softwarelösungen aus der Arbeitswelt von Administratoren nicht mehr wegzudenken. Immer mehr Produkte und cloudbasierte Dienste lassen sich nur per PowerShell und individuelle Skripte sinnvoll administrieren. Gerade Office 365 ist hier ein unrühmliches Beispiel, da jeder Dienst über eine individuelle PowerShell-Schnittstelle verfügt.
Dieser Umstand hat zur Folge, dass Sie als Administrator oft Skripte zur Verwaltung komplexer Umgebungen einsetzen müssen, die Sie nicht selbst geschrieben haben. Die Skripte werden entweder von externen Dienstleister programmiert oder einfach aus dem Internet heruntergeladen. Hierbei implementiert jedes Skript, im Idealfall, eine eigene Protokollierung der ausgeführten Aktionen.
Die PowerShell-Skripte sind in den meisten Fällen für die individuelle Ausführung durch einen Administrator konzipiert und weniger für die regelmäßige und vollautomatische Ausführung. Als Administrator möchten Sie sich aber um wichtiger Dinge kümmern, als z.B. die Anlage von Benutzerkonten im Active Directory, die E-Mail-Aktivierung von Konten oder die Erstellung von SharePoint Team-Sites.
Sie stehen u.a. vor folgenden Problemen:
Sie kommen mit der Nutzung der Windows Bordmitteln, wie dem Task Scheduler, schon recht weit. Aber Sie werden mir zustimmen, dass dieses Tool nicht gerade die bequemste Art ist, um PowerShell-Skripte sinnvoll und sicher zu automatisieren.
Ein Lösung für dieses Dilemma ist die Nutzung einer Softwarelösung, die uns ein Trennung zwischen dem ausführenden Skript-Kontext und dem Kontext des Anwenders, der ein Skript startet, bietet. Mit einem Rollen- und Berechtigungssystem kann ein Skript, in Abhängigkeit der Rollenzuweisung, unterschiedlich ausgeführt werden.
WIr benötigen also ein Lösung, die uns folgende Funktionen bietet:
Mit ScriptRunner steht eine professionelle Softwarelösung zur Verfügung, die uns all diese Möglichkeiten bietet. ScriptRunner ist ein sehr umfangreiches und leistungsfähiges Produkt zur PowerShell-Automatisierung. Aus meiner Sicht ist das Sicherheitskonzept, das für die Delegierung der Skript-Ausführungen eingesetzt wird, einer der Hauptgründe für das Produkt.
Das folgende Schaubild vereutlicht die Isoliserung von ScriptRunner für die sichere Ausführung von PowerShell-Skripten.
Grafik © ScriptRunner
Die einzelnen Schritte sind:
Die Automatisierung und die wiederkehrende Ausführung führt zu einer Reduzierung der Betriebsrisiken und minimiert kostenintensive manuelle Nacharbeiten. Dies gelingt durch die hohe Reproduzierbarkeit der immer gleichen Aufgaben (Stichwort: Erstellung von Benutzern mit unterschiedlichen Attributen, je nach Fachabteilung). Durch ein Zonenmodell und die strikte Trennung der Ausführungsberechtigungen (Anwender, Automatisiserungsdienst, Skript-Credentials) erreichen Sie ein Maximum an Betriebssicherheit.
Mit solch einer Aufteilung können Sie die Ausführung von Skripten nicht nur an das Helpdesk-Team delegieren, sondern sogar an DV-Ansprechpartner in Fachabtielungen. Die Weboberfläche ist intuitiv bedienbar und führt den Anwender sucher durch alle konfigurierten Eingabe- und Auwahlschritte.
Ab Q1 2019 werden Sie speziell für Exchange Server, Exchange Online und Office 365 entwickelte Skripte zur Nutzung mit ScriptRunner in diesem Blog finden.
Viel Spaß bei der Automatisierung!
Mit dem De-Mail Gesetz vom 28. April 2011 sollte ein neues Zeitalter der sicheren und verschlüsselten E-Mail Kommunikation zwischen Behörden, Unternehmen und Bürgern eingeläutet werden. Das Gesetz regelt die De-Mail-Dienste, die Akkreditierung von De-Mail-Anbietern, die Durchführung der Aufsicht und den Zugang zu De-Mail. De-Mail wurde mit der Intention ins Leben gerufen, die Verbreitung der Ende-zu-Ende Verschlüsselung zwischen E-Mail-Absendern und -Empfängern zu fördern.
Aktuell werden De-Mail-Dienstleistungen von vier Anbieter bereitgestellt:
Der Erwerb einer eigenen De-Mail-Domäne, wie z.B. varunagroup.de-mail.de, ist für Unternehmenskunden nur über einen der akkreditierten Anbieter möglich. Nach Erwerb der De-Mail-Domäne ist auch eine Gateway-basierende Anbindung für den Versand und Empfang von De-Mail-Nachrichten über diesen Anbieter möglich. Der Anbieter selber stellt hierbei die E-Mail-Verschlüsselung nach De-Mail-Standard sicher.
Die Informationen zum Erwerb einer De-Mail-Adresse bzw. De-Mail-Domäne ist bei den vier akkreditierten Anbietern unterschiedlich gut auffindbar.
Bei 1&1 ist das Produkt De-Mail relativ gut in der zweiten Menüebene zu finden. 1&1 versucht De-Mail Kunden mit einem finanziellen Einsparpotential gegenüber normaler Post zu locken. Hier ist allerdings bisher niemandem aufgefallen, dass mit leicht veralteten Zahlen auf den Jahren 2007, 2008 und 2010 gearbeitet wird. Ein De-Mail-Gateway, zur Integration in die IT-Infrastruktur wird für Unternehmenskunden augenschainlich nicht angeboten.
Mentana-Claimsoft räumt dem Produkt De-Mail mehr Aufmarksamkeit ein. De-Mail ist der erste Menüpunkt der Hauptnavigation. Die bereitgestellten Informationen lassen darauf schließen, dass Unternehmenskunden die Hauptzielgruppe sind. Es werden zwei unterschiedliche Optionen für eine De-Mail-Anbindung angeboten. Die erste Option besteht aus einer Gateway-Software-Lösung, die auf Java-Runtime 1.6 (32-bit) basiert und nur, laut Dokumentation, ältere Windows-Betriebssysteme, wie Windows 7/8 oder Windows Server 2008R2/2012, unterstützt. Als zweite Anbindungsvariante steht eine Web Service Integration zur Verfügung, für die allerdings eine Testintegration angefragt werden muss. Eine Bestellung kann über die Webseite nicht ausgelöst werden. Vielmehr darf man sich telefonisch an das Service Center De-Mail wenden.
Die T-Systems International GmbH versteckt De-Mail in der vierten Menüebene. Auf dem Weg in diese Ebene (Lösungen -> Security -> Lösungen -> De-Mail) trifft man auf aktuelle Buzz-Words zum Thema Cloud. Auch bei T-Systems wird zuerst mit dem preislichen Vorteil gegenüber der klassischen Briefpost geworben. Auf der Seite wird viel und bunt über De-Mail geschrieben und auf eine weitere Unterseiten verlinkt. Ein direkter Link zum Erwerb einer De-Mail-Domäne ist nicht auffindbar. Der Erwerb einer De-Mail-Domäne scheint nur in einem Beratungstermin möglich.
Die Telekom Deutschland GmbH bietet ebenfalls das Produkt De-Mail an. In der Menüstruktur der Hauptseite sucht man De-Mail allerdings vergebens. Das Produkt ist im Bereich des Menüpunktes Cloud & IT versteckt (Cloud & IT -> Sicherheit & Effizienz -> Für Daten & Mails) und befindet sich dort auf der Detailseite neben der Mobile Encryption App und BusinessMail X.400. Der einladende Link Jetzt Bestellen führt leider nicht zu einer Online-Bestellung, sondern zu einer Übersichtsseite für PDF-Formulare, um diese herunterzuladen und per Fax zurückzusenden. Die Telekom bietet unterschiedliche Leistungspakte für Geschäftskunden an. Man kann De-Mail ohne eigene Gateway-Lösung über das Web-Portal (einfache Variante) oder mit dem De-Mail-Gateway (Profi-Variante) nutzen. Der Erwerb einer De-Mail-Domäne ist bei der Telekom nur über die Nutzung von PDF-Formularen möglich.
In einem Kundenprojekt konnte ich Erfahrungen mit De-Mail und der Anbindung mit dem E-Mail-Security-Gateway NoSpamProxy sammeln. Der Vorteil dieser Lösung ist, dass kein separates De-Mail-Gateway, dass von den Anbietern in Eigenregie entwickelt wurde, implementiert und betrieben werden muss. Stattdessen wird ein ausgereiftes E-Mail-Gateway Produkt verwendet, dessen De-Mail-Integration per Web Services auf die Schnittstelle des ausgewählten De-Mail-Anbieters zu greift. So ist der De-Mail-Versand in den regulären E-Mail-Verkehr eingebettet und durchläuft alle E-Mail-Prozesse für zentrale Signaturen und rechtssichere Archivierung.
Als Bestandkunde der Telekom lag es natürlich nahe, die De-Mail-Domäne über die Telekom Deutschland GmbH zu beziehen.
So beginnt die Reise...
Aber alles beginnt mit der Registrierung einer De-Mail-Domäne, um im E-Mails im Format info@varunagroup.de-mail.de versenden zu können. Wie schon erwähnt, öffnet ein Klick auf die Schaltfläche Jetzt Bestellen, auf der Telekom De-Mail-Webseite, eine eindrucksvolle Liste von PDF-Formularen.
Vergebens suchte man eine PDF-Nutzungsanleitungsbeschreibung. Aber das Formular mit dem Titel Auftrag für ein Business De-Mail-Konto sah vielversprechend aus.
Randnotiz: Interessant ist, dass diese Formulare unter dem Punkt Ihre Vorteile im Überblick verortet sind.
Im PDF-Formular wird glücklicherweise der Zweck des Formulars beschrieben: Mit diesem Formular können Sie ein De-Mail Konto beauftragen
Das Ausfüllen fiel nicht sonderlich schwer . Das ausgefüllte und unterschriebene Formular fand, inklusive zusätzlich benötigter Dokumente, anschließend seinen Weg per Fax an die im Formular genannte Faxnummer.
Danach passierte erst einmal... nichts.
Am 19. April schrieb ich eine freundliche E-Mail an den Geschäftskunden-Service der Telekom, in der ich die Situation schilderte und um Mithilfe bei der Identifikation der Telekom-internen Ansprechpartner für das Thema De-Mail bat. Die Reaktion erfolgte prompt. Meine Original-E-Mail wurde, um einen kleinen Hinweis ergänzt, an das De-Mail-Team (De-Mail@telekom.de) weitergeleitet.
Auf diese E-Mail erfolgte eine telefonische Kontaktaufnahme durch das De-Mail-Team der Telekom. Die Grundinformation des Telefonats war leider ernüchternd. Es lag keine Beauftragung per Fax vor.
Am 24. April wurde der Antrag auf eine De-Mail-Domäne als PDF-Dateianhang, mit der Bitte um eine Auftragsbestätigung, an das De-Mail-Team der Telekom per E-Mail (S/MIME signiert) gesendet. Die erfolgreiche SMTP-Zustellung wurde im E-Mail-Gateway protokolliert.
Danach passierte erst einmal - nichts.
Am 24. Mai wurde der Antrag auf eine De-Mail-Domäne als PDF-Dateianhang, mit der Bitte um eine Auftragsbestätigung, zum dritten Mal an das De-Mail-Team der Telekom per E-Mail (S/MIME) gesendet. Die erfolgreiche SMTP-Zustellung wurde abermals im E-Mail-Gateway protokolliert.
Es ist immer noch nichts passsiert. Keine Reaktion per Telefon, per E-Mail oder per Post.
Ich kann mich des Eindrucks nicht erwehren, dass die Telekom keine Neukunden für den Dienst De-Mail gewinnen möchte. Der Dienst scheint eine Art lästiges Pflichtprogramm zu sein. Auch das wäre zu verstehen, wenn es eine angemessene Reaktion des De-Mail-Teams geben würde.
Die Untätigkeit auf der Anbeiterseite verleitet naturgemäß zu Aktionismus. Nachdem ich heute den Telekom Login erneutet habe, stolperte ich in der Vertragsübersicht über die Option, sich doch direkt für De-Mail Web zu registrieren bzw. einen Beratungstermin für das De-Mail Gateway zu vereinbahren.
Leider führt der Link Beratung vereinbaren auf die bereits bekannte Seite zur Digitalisierung meiner Post. Der auf dieser Seite befindliche Link Jetzt Bestellen leitet mich wieder zu den PDF-Formularen und ist somit eine Sackgasse.
Ist es Zufall, dass sich die aktuelle Ausgabe (Juli 2018) der brand eins mit dem Thema Service befasst?
Der Monatstitel des Magazins ist
Die Wüste lebt.
Gestern hat mich die Deutsche Telekom angerufen. Man hätte gehört, dass ich Probleme mit der Beauftragung einer De-Mail-Domäne hätte. (Frei zitiert)
Nach Angabe der Telekom Kundennummer hat man mir versprochen, dass sich ein Berater für De-Mail in der nächsten Woche telefonisch bei mir melden wird, da ich ja nicht die Standardlösung betreiben möchte, sondern eine De-Mail-Dirttanbieterlösung (in diesem Fall NoSpamProxy).
Ich bin gespannt...
Freitag der 13. muss nicht immer ein Tag für ein schlechtes Omen sein. Heute hat mich ein De-Mail-Berater von T-Systems angerufen. Er hat mir in einem sehr ausführlichen Telefonat die Herausforderungen der De-Mail-Bestellprozesse dargelegt (was sehr unterhaltsam war). Um nun eine schnelle Beauftragung in die Wege leiten zu können, läuft die Beauftragung nun nicht über die Telekom Deutschland, sondern über die T-Systems. Schon wenige Minuten nach dem Telefonat fanden die vorausgefüllten Auftragsformulare ihren Weg in den Posteingang meines E-Mail-Postfaches.
"De-Mail Auftragsbestätigung"
Ich hätte nicht gedacht, dass ich diesen E-Mail-Betreff noch einmal lesen darf. Nachdem ich heute die ausgefüllten und unterschriebenen Dokumente per E-Mail an den De-Mail-Berater bei der T-Systems gesendet hatte, dauerte es weniger als zwei Stunden, bis der Auftrag im T-Systems Buchungssystem erfasst war und ich die Bestätigung erhielt.
Nun bedarf es nur noch der Umsetzung des Auftrages.
Inzwischen sind alle notwendigen Unterlagen und Gerätschaften (Signaturkarten inkl. Lesegerät, Software) eingetroffen. Ich konnte mich erfolgreich am T-Systems De-Mail Webportal anmelden und die erste De-Mail erfolgreich versenden. Sehr positiv zu bewerten ist, dass die Multi-Faktor Authentifizierung sofort funktioniert hat.
Die Nutzung des De-Mail Web Portals ist natürlich kein Dauerzustand. Ziel ist die Integration in den normalen E-Mail-Workflow und die direkt Nutzung aus dem Outlook-Client heraus. Hierzu werde ich die vorhandene E-Mail-Gateway-Lösung NoSpamProxy an die T-Systems De-Mail Web Service Schnittstelle anbinden und das NoSpamProxy Outlook Add-In verwenden. Diese Konfiguration wird von einem separaten Blog-Artikel begeleitet.
Mein persönlicher Eindruck ist, dass die vier akkreditierten Anbieter das Produkt De-Mail vor potentiellen Kunden verstecken möchten. Vor dem Hintergrund, dass die Bundesregierung, als Wegweiser und Urheber eines digitalen Fahrplanes, immer noch auf das Thema De-Mail setzt und De-Mail sogar aus dem Ausland nutzbar machen möchte, ist dies eine Farce.
Man stellt sich als Geschäftskunde zwangsläufig die Frage, warum der Prozess für De-Mail so kompliziert sein muss und wer sich dieses Prozessmonster ausgedacht hat.
An meinem grundlegenden Fazit hat sich nichts geändert. Die Schwierigkeit bei der Beauftragung von De-Mail für Unternehmen liegt darin, einen kompetenten Ansprechpartner zu identifizieren. Wenn man diese Hürge genommen hat geht es recht zügig weiter. Im Rahmen einer De-Mail Beauftragung ist natürlich auch eine Verifizierung der Identität des Beauftragendfen erforderlich. Interessanterweise stehen die gängigen Methoden zur Überprüfung nicht zur Verfügung. In diesem Fall erweisen sich das BSI und das BKA als Bremser der De-Mail und nicht die akkreditierten Anbieter.
Die folgenden Ident-Methoden stehen nicht zur Verfügung:
Mögliche Ident-Methoden sind:
Es bleibt somit weiterhin kompliziert.
Trotz alledem - Viel Spaß mit De-Mail
Wenn Sie Fragen zum Thema De-Mail haben, freue ich mich über eine E-Mail: thomas.stensitzki@granikos.eu