Mit SMIME-Verschlüsselung lassen sich E-Mails sicher verschlüsseln. Ich beschreibe, wie wir SMIME an unserer Schule eingeführt haben.
Transkript
Das Transkript wurde maschinell erstellt und kann Fehler enthalten. Es zählt
das gesprochene Wort.
Ausklappen
00:00–0:00:14
Hallo und herzlich willkommen zu Bildungsfern Ausgabe 17 vom 1.4.2020. Ich berichte hier aus
0:00:14–0:00:22
Sicht eines Berufsschullehrers, wie sich das jetzt so anfühlt in der Schulschließung und ja jetzt
0:00:22–0:00:29
dieser Unterrichtsausfall oder wie er denn auch so stattfindet, wahrgenommen wird. Zum einen eben
0:00:29–0:00:34
ja hauptsächlich aus der Lehrerperspektive, aber vielleicht bald auch noch ergänzt durch
0:00:34–0:00:40
eine Schülerperspektive. Da gibt es ein paar Planungen in diese Richtung. Da werdet ihr in
0:00:40–0:00:46
einer der nächsten Folgen auf alle Fälle noch mehr erfahren zu. Heute geht es noch mal um
0:00:46–0:00:53
Verschlüsselung beziehungsweise um E-Mails, die zum Beispiel mit Hilfe von S-MIME verschlüsselt
0:00:53–0:00:57
werden können. Da wollte ich mal ein paar Worte zu verlieren, weil ich glaube so Vertraulichkeit und
0:00:57–0:01:04
Datenschutz spielt gerade jetzt in den Zeiten, wo aus der Ferne sensible Daten übertragen werden,
0:01:04–0:01:11
eine große Rolle. Ich hatte mal bei Wikipedia nachgeguckt. S-MIME steht für "Secure Multi-Purpose
0:01:11–0:01:18
Internet Mail Extension" und das ist eine Möglichkeit E-Mails zu verschlüsseln. Was man
0:01:18–0:01:25
dafür benötigt ist ein Zertifikat, das kann man sich eigen, also rein technisch könnte man
0:01:25–0:01:30
es sich einfach selbst generieren und dann auf seinen Computer benutzen, um anderen damit
0:01:30–0:01:38
Mail verschlüsselte Mails zu schicken. Das Problem ist, dass diese Zertifikate dann auf
0:01:38–0:01:43
der anderen Seite als nicht vertrauenswürdig eingestuft werden, weil man sie selber generiert
0:01:43–0:01:51
hat. Deswegen gibt es Anbieter, die einem Vertrauen verkaufen und dann sagen, dieses Zertifikat,
0:01:51–0:01:59
das ist in Ordnung, das ist hier von dem Mako und insofern, das könnt ihr nehmen. Ja, wir haben einen
0:01:59–0:02:09
Anbieter, der nennt sich "Sektigo" und bei dem haben wir Zertifikate dann eingekauft und da wollte
0:02:09–0:02:15
ich mal erklären, wie das bei uns abläuft, wie da der Prozess im Moment ist und da ließe sich
0:02:15–0:02:19
sicherlich noch was optimieren. Vielleicht habt ihr auch Anregungen oder Ideen, wie man so was
0:02:19–0:02:24
eigentlich macht oder deutlich besser. Jemand, der so was vielleicht schon mal in einem Unternehmen
0:02:24–0:02:30
eingeführt hat und hier mithört, der also kann sich gerne da auch mal an mich wenden. Wir sind
0:02:30–0:02:34
da auf alle Fälle noch viel am Lernen, deswegen ja auch die berufliche Bildung. Wir lernen ja
0:02:34–0:02:41
auch noch dazu und genau, also wie läuft das ab? Zunächst zum Prozess. Der Benutzer erhält
0:02:41–0:02:48
einen Token, einen Admin, der erstellt auf der Administrationsseite von Sektiko ein Token und
0:02:48–0:02:54
das wird demjenigen dann per E-Mail zugestellt. Mit Hilfe dieses Tokens kann er sich dann auf
0:02:54–0:03:00
einer Webseite anmelden und sein Schlüsselpaar privat öffentlich generieren. Das macht er im
0:03:00–0:03:06
Browser bzw. der Browser selbst macht das. Deswegen können das auch nicht alle Browser,
0:03:06–0:03:15
also da gibt es eine gewisse, eigentlich nur zwei, ich glaube der Internet Explorer war es und Safari
0:03:15–0:03:21
und das war es dann auch. Also damit muss man einmalig ein Schlüsselpaar generieren und das
0:03:21–0:03:27
dann irgendwie aus dem Browser herausfummeln und dann erhält man eine Datei und die kann man dann
0:03:27–0:03:36
an beliebigen Stellen in irgendeiner Form dann ablegen. So dieser Schlüssel, den ich dann habe,
0:03:36–0:03:41
der wird dann also irgendwo importiert, vorzugsweise zum Beispiel einfach in Mail
0:03:41–0:03:46
Client, aber meist ist das auch schon irgendwo im Betriebssystem, gibt es da eine Schlüsselverwaltung
0:03:46–0:03:52
oder Schlüsselbund heißt das unter macOS, wo solche Zertifikate abgelegt werden standardmäßig.
0:03:52–0:03:56
Unter macOS war es ziemlich einfach, ich habe einfach einen Doppelklick auf die Datei gemacht
0:03:56–0:04:04
und die Sache war gegessen. Bei Thunderbird habe ich es so gemacht, dass ich in den Einstellungen die
0:04:04–0:04:09
Schlüsseldatei einfach ausgewählt habe und dann importiert habe. Das war eigentlich auch ohne
0:04:09–0:04:17
größere Schwierigkeiten schnell erledigt, ist damit aber dann eben nicht im Betriebssystem drin. Nachdem
0:04:17–0:04:24
die Kollegen das dann gemacht haben, haben sie einmal eine Mail an das gesamte Collegium geschickt,
0:04:24–0:04:31
sodass alle dann auch dieses öffentliche Zertifikat von dieser Person erhalten haben und
0:04:31–0:04:40
damit dann in Zukunft an diese Person verschlüsselt schicken können. Bedeutet also, ich habe dann
0:04:40–0:04:46
einmal ans Collegium geschickt, mein öffentlicher Schlüssel ist damit dann an alle verteilt und die
0:04:46–0:04:52
Clients auf der anderen Seite, wenn sie diese Mail empfangen, ziehen den Schlüssel daraus und können
0:04:52–0:04:58
dann diesen Schlüssel für die Zukunft benutzen, um mir verschlüsselt etwas zuzuschicken. Das hat
0:04:58–0:05:02
erstaunlicherweise ziemlich gut geklappt, erstaunlicherweise sage ich, weil es bei PGP
0:05:02–0:05:07
deutlich komplizierter war in der Verwendung, dafür ist die Schlüsselgenerierung deutlich leichter,
0:05:07–0:05:18
außer bei Outlook. Outlook geht da so einen kleinen Sonderweg, das ist scheinbar irgendwie
0:05:18–0:05:24
ein größeres Problem, weil Outlook nicht auf den Zertifikatsspeicher des Betriebssystems zugreift
0:05:24–0:05:30
und auch keinen eigenen hat. Zumindest ist es in unserem Falle bei der Office 365 Installation so
0:05:30–0:05:41
und deshalb muss die Root CA und auch alle Zertifikate dann in Office 365 hinterlegt werden.
0:05:41–0:05:47
Es gibt da ein Konstrukt, das nennt sich GAL, das steht für Global Address List, also so eine Art
0:05:47–0:05:53
globales Adressbuch, wo alle Adressen drinstehen und in dieser Global Address List werden dann
0:05:53–0:06:01
auch die Zertifikate hinterlegt und nachdem wir das herausbekommen hatten, gab es dann auch keine
0:06:01–0:06:09
Probleme mehr mit Outlook. Das war allerdings auch jetzt nicht so einfach, also da gibt es in der
0:06:09–0:06:13
Admin Oberfläche im Web nicht direkt eine Option, so hier hast du einen Schwung von Zertifikaten,
0:06:13–0:06:22
benutze mal bitte, sondern das geht nur über die PowerShell und spezielle Commandlets oder wie die
0:06:22–0:06:26
heißen, die man dann dafür verwenden kann. Ein Kollege hatte sich darum gekümmert, weil ich jetzt
0:06:26–0:06:34
nicht so Windows-affin bin und dann hat es aber dann auch wieder funktioniert. Das hat jetzt am
0:06:34–0:06:42
Ende dazu geführt, dass wir von 80-90 Kollegen jetzt 60 oder eben auch mehr dazu bekommen haben,
0:06:42–0:06:47
jetzt verschlüsselt E-Mails empfangen und versenden zu können. Jetzt wird sich in Zukunft dann
0:06:47–0:06:52
herausstellen, wie das auch dann im Alltag so funktioniert. Müssen wir dann mal schauen,
0:06:52–0:06:59
welche Probleme da im Alltag dann auftreten könnten. Wir haben da schon so ein paar Ideen,
0:06:59–0:07:05
was auftreten könnte, also natürlich spätestens, wenn die Zertifikate ablaufen, das ist in drei
0:07:05–0:07:10
Jahren der Fall, muss dieses gesamte Prozedere wiederholt werden und da ist unklar, inwieweit da
0:07:10–0:07:21
die Bereitschaft besteht, dieses ganze noch mal durchzuführen. Anderes Problem, was wir vermuten,
0:07:21–0:07:27
ist, dass dadurch zum Beispiel die Volltext-Suche in den Mail-Client eingeschränkt wird, weil ja
0:07:27–0:07:30
eben die Mails verschlüsselt ausgetauscht werden, gibt es dann nicht mehr die Möglichkeit, einfach
0:07:30–0:07:36
irgendwas einzugeben und die Mail mit dem entsprechenden Inhalt wird dann gefunden. Auch
0:07:36–0:07:41
unklar ist, ob das Auswirkungen auf die Performance hat, also ich muss jetzt mehr machen als Mail-Client,
0:07:41–0:07:47
Verschlüsseln, Entschlüsseln etc. Scheint bisher kein Problem zu sein, mal gucken, wie sich das so
0:07:47–0:07:53
dann anhält, wenn es recht viele Mails werden. Normalerweise hat der Mail-Client damit nichts zu
0:07:53–0:07:57
schaffen, denn er speichert sie einfach nur weg und nur beim Öffnen oder Schließen könnten da
0:07:57–0:08:04
Probleme auftauchen, deswegen ist es vermutlich nicht der Fall. Ein weiteres Problem sind mobile
0:08:04–0:08:14
Endgeräte. Wir haben es jetzt getestet für die Outlook-App unter iOS und Android, Car-Mail glaube
0:08:14–0:08:21
ich und noch Fair-Mail unter Android. Das sind noch zwei Mail-Clients, bei denen manuell diese
0:08:21–0:08:27
Zertifikate jeweils durch Lesen einer Mail und dann Importieren Zertifikat für jeden Empfänger
0:08:27–0:08:32
einzeln importiert werden müssen. Das ist ein bisschen umständlich und da wünsche ich mir
0:08:32–0:08:38
eigentlich mehr Automatisierung. Da muss man dann mal schauen, inwiefern man das machen möchte.
0:08:38–0:08:46
Rein datenschutzrechtlich, private Endgeräte und Kommunikation von Lehrern ist sowieso ein
0:08:46–0:08:53
Problem, denn eigentlich muss man sich das genehmigen lassen von der Schulleitung und dann ist das auch
0:08:53–0:08:58
in gewisse Bedingungen geknüpft. Zum Beispiel ist das an die Bedingungen der Kontentrennung. Also
0:08:58–0:09:04
man muss dann ein separates Konto auf dem Handy einrichten, also ein Benutzerkonto, was dann
0:09:04–0:09:10
getrennt von dem privaten Konto geführt wird. Ich wage mal zu bezweifeln, dass das in der Praxis
0:09:10–0:09:17
tatsächlich umgesetzt wird, aber man unterschreibt es dann und die Handreichungen, die es da in NRW
0:09:17–0:09:23
gab, die erfordern das eigentlich. Wir haben es jetzt auf jeden Fall schon mal umgesetzt. Ich bin
0:09:23–0:09:30
gespannt, was jetzt noch so draus wird, wie es sich dann in Zukunft weiter angehen wird. Ich bin auf
0:09:30–0:09:36
alle Fälle froh, dass wir jetzt so eine Möglichkeit haben, sensible Daten damit auszutauschen und man
0:09:36–0:09:39
fühlte sich ja dann doch irgendwie immer so ein bisschen schmutzig, wenn man das per Mail
0:09:39–0:09:46
verschickt hat. Gerade jetzt, wo eben kurz vor den Osterferien einige Prüfungslisten ausgetauscht
0:09:46–0:09:50
werden und auch Notenlisten, Prüfungsvorschläge und das war immer so, ja man musste sich dann
0:09:50–0:09:54
irgendwie ein Passwort überlegen und damit hat man dann das Dokument verschlüsselt, aber dafür
0:09:54–0:09:58
musste man sich vorher treffen und das Passwort vereinbaren und das ist jetzt in der jetzigen
0:09:58–0:10:04
Situation natürlich nicht so einfach und deshalb ist es auf alle Fälle gut, wenn wir jetzt diese
0:10:04–0:10:10
Möglichkeit geschaffen haben. Ok, das war es dann schon wieder für heute. Ich hoffe, es war auch
0:10:10–0:10:16
ein bisschen interessant für euch und verbleibe bis dahin. Ich wünsche euch alles Gute, bleibt
0:10:16–0:10:21
gesund, wascht euch die Hände, bleibt zuhause. Bis dahin und tschüss.
