Teil 2: VerSAMLung – SSO mit SAML oder KCD für interne Webservices

(von Stefan Kuscher und Benjamin Rodewald)

Im ersten Teil unserer Serie „verSAMLung“ haben wir den Citrix Application Delivery Controller (ADC) als SP an die MS Azure MFA Authentifizierung (als IdP) angebunden und so die bequeme und transparente Nutzung von Applikationen auf dem Citrix ADC möglich gemacht, welche mit einer Pre-Authentifizierung geschützt sind.

Bisher muss man sich nach der Anmeldung am Azure (welche der ADC nutzt) noch immer an der eigentlichen Applikation anmelden, aber auch dafür gibt es eine Lösung. Der ADC bietet die Möglichkeit Anmeldedaten zu extrahieren und die diese auch für den Single Sign On im Backend zu benutzen. Im einfachsten Fall, könnte die dem ADC bekannte Username/ Kennwort Kombination z.B. für eine 401 Header Based Authentication genutzt werden, hierfür wäre lediglich eine Traffic Policy, welche Web Single Sign On anschaltet, notwendig.

In Verbindung z.B. mit SAML oder Certificate based Authentication ist das Vorgehen ein klein wenig komplizierter, da auf dem ADC keine Anmeldedaten vorliegen (was dem Sicherheitsniveau natürlich sehr zuträglich ist). Hier muss ein Verfahren genutzt werden, welches alleine mit den im SAML Token vorhandenen oder im Zertifikat vorhandenen Informationen auskommt. Neben der Möglichkeit hier im Backend ebenfalls SAML für den SSO zu benutzen, gibt es die Möglichkeit Kerberos Constrained Delegation (KCD) zu nutzen. Da sämtliche Applikationen aus dem Windows Umfeld damit sehr einfach angebunden werden können, bietet sich diese Möglichkeit oft an um eine Applikationen zu verSAMLen (SAML fähig zu machen).

DNS und NTP auf dem ADC

Wie auch in den späteren Logs erkennbar sein wird, benötigt der Netscaler für die Nutzung von Kerberos eine funktionierende DNS Auflösung der Windows Active Direcory Domain und eine per NTP korrekt synchronisierte Uhrzeit. Für die Domain/ den DC kann theoretisch auf dem Netscaler auch manuell ein Ressource Record hinzugefügt werden. Zur Zeitsynchronisation sind idealerweise mindestens zwei NTP Server einzutragen und die Synchronisation einzuschalten.

Konfiguration AD Account / Delegation

Bei der Constrained Delegation wird ein Servcie Benutzer für den ADC angelegt, dem dann die Delegierung (Zugriff im Auftrag eines anderen Benutzers) erlaubt wird:

Nachdem der Benutzer angelegt wurde, muss der HOST SPN gesetzt werden, damit die Regsiterkarte „Delegation“ erscheint:

setspn -S HOST/[Name d. Deleg.-konto].[FQDN] [NetBIOS-Domainname]\[Name d. Deleg.-konto]

Setzen des Host SPN
Kerberos Delegierungskonto 1/2

Auf der Registerkarte „Delegation“ des Accounts wird dann die eigentliche Delegierung konfiguriert, der Service SPN „http/demoweb.mwdemo.local@MWDEMO.LOCAL“ für einen internen Microsoft IIS Webserver.

Kerberos Delegierungskonto 2/2

Konfiguration KCD auf dem ADC

Für den Account wird dann auf dem ADC ein KCD Objekt erstellt, welches in einer Traffic Policy eingebunden wird:

ADC / KCD-Account
add aaa kcdAccount wiakcd_appdelegation -realmStr MWDEMO.LOCAL -delegatedUser appdelegation -kcdPassword b616477dhgkjifdghuidf4757747593458930580f -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_yy_yy_yy8 -userRealm MWDEMO.LOCAL -serviceSPN "http/demoweb.mwdemo.local@MWDEMO.LOCAL"

Steuerung SSO mittels Traffic Policy und Profile

Mittels einer Traffic Policy und einem Traffic Profile, welches auf dem Load Balancing Vserver gebunden wird, wird gesteuert an welchen Stellen die KCD SSO Settings angewendet werden sollen:

Traffic Profile (unten ist der KCD Account ausgewählt)
add tm trafficAction prof_traf_wia_demoweb_kcd -SSO ON -persistentCookie OFF -InitiateLogout OFF -kcdAccount wiakcd_appdelegation

Traffic Policy über die das o.g. Profile angebunden wird
add tm trafficPolicy pol_traf_wia_demoweb_kcd true prof_traf_wia_demoweb_kcd

Debugging

Ein Debugging ist mittels cat /tmp/nkrb.debug möglich.

Bei unserem ersten Versuch in der Demo Umgebung gab es wegen den unterschiedlichen Realms in Verbindung mit dem Azure AD noch Probleme:

Log Fehler

Wir haben daraufhin in den KCD Settings das Feld „User Realm“ ergänzt, dies verhindert, dass wie oben eine Cross Realm Authentifizeirung zwischen Azure AD und AD Domäne versucht wird. Somit wird die Anfrage „Username@michaelwesseldemo.onmicrosoft.com“ zu der passenden Anfrage „Username@mwdemo.local“ umgewandelt. Dieser „Workaround“ betrifft unserer Testumgebung aufgrund der fehlenden routingfähigen Domäne.

Hier die Logs des Erfolgsfalls:

Log Erfolg – 1
Log Erfolg – 2
Log Erfolg – 3
Log Erfolg – 4
Log Erfolg – 5
Log Erfolg – 6
Log Erfolg – 7

Teil 1: VerSAMLung – Microsoft Azure SSO am Citrix ADC mit SAML

(von Stefan Kuscher und Benjamin Rodewald)

Im Nachfolgenden erläutern wir die Vorteile, wenn Citrix ADC und Azure Active Directory verSAMLt sind und wie wir dies umgesetzt haben.

Folgende Vorteile ergeben sich:

  • Benutzer muss lediglich beim Anmelden am Arbeitsgerät ein Passwort eingeben (SSO) und ist somit automatisch beim Citrix ADC bekannt und bestenfalls alles was mit diesem verknüpft ist. Von dort aus kann z.B. der Zugriff auf Applikationen wie Citrix Xenapp/XenDesktop oder auch Web-Applikationen erfolgen. (Ohne zusätzliche Anmeldung)
  • Azure AD als der Zugangspunkt für Benutzer.
  • Benutzersteuerung/Berechtigungsverwaltung zentral in Azure AD.
  • Conditional Access\Begrenzter Zugriff + MFA (Azure AD P1 Lizenz)

Voraussetzungen

Ablauf

Abbildung Ablauf SAML

Das SAML Protokoll wurde geschaffen um über eine Teilung in Identity Provider (IdP) und Service Provider (SP) die Authentication für Zugriffe zu ermöglichen. Dabei kann sofern eine Applikation z.B. aus der Cloud bezogen wird, trotzdem gegen einem IdP, der unter Kontrolle des eigenen Unternehmens steht authentifiziert werden (in unserem Falle ist dieser in der Cloud als MS Azure AD ausgeprägt). Der SAML SP (AAA auf dem ADC) vertraut diesem IdP und lässt den Request beim Vorhandensein der Authentifizierungsinformationen passieren. Sind die Informationen nicht vorhanden, würde der Citrix ADC auf die Anmeldeseite des SAML IdP weiterleiten.

In unserem speziellen Fall meldet das Gerät bereits beim MS Windows Logon den Benutzer in der Cloud beim Azure AD an. Der Benutzer besitzt daher zum Zeitpunkt seines ersten Zugriffs schon die entsprechenden Anmeldeinformationen und der ADC (bzw. die AAA / SP Komponente) lässt den Benutzer mit SSO passieren.

Deployment einer Enterprise Applikation in Azure (IDP)

Um eine Kommunikation mit dem Citrix ADC via SAML herzustellen benötigt man auf der Azure Active Directory Seite eine Enterprise Applikation. Diese wird im Azure Active Directory -> Enterprise Applications -> New Application
bereitgestellt und wird benötigt um sich mit dem SP per SAML auszutauschen.

Auswählen einer Vorlage im Browse Azure AD Gallery für das Citrix SAML Add On
Microsoft bietet bereits diverse Vorlagen für Enterprise Applikationen an. In unserem Fall benötigen wir die Vorlage „Cirix ADC SAML Connector for Azure AD“.

In der Enterprise Applikation müssen die benötigten Informationen wie Identifier, Reply URL und Sign On URL des Citrix ADC hinterlegt werden.

1.) Enterprise Applikation -> Name der APP -> Single Sign-on
Identifier: https://FQDN
Reply URL: http(s)://FQDN der WebApplication/cgi/samlauth
Sign On URL: https://FQDN/CitrixAuthService/AuthService.asmx


Ebenfalls finden sich dort die Informationen die der Citrix ADC im späteren Verlauf benötigt z.B. die Login URL von Azure Active Directory oder die Metadaten URL.

2.) Mittels Metadaten URL kann der Austausch der Informationen zwischen AAD und ADC automatisch erfolgen. Voraussetzung hierfür ist dass die Version des CItrix ADC den Austausch via Metadaten bereits unterstützt.

3.) Falls ein Austausch via Metadaten nicht in Frage kommt ,können die Informationen auch manuell dem Citrix ADC übergeben werden (Login URL, Zertifikat…).

Screenshot aus dem Citrix ADC SAML Connector

Berechtigungskontrolle für die Enterprise Applikation

Im Anschluss müssen die Benutzer noch die Berechtigungen erhalten, um die Enterprise Applikation nutzen zu können. In unserem Fall stellen wir die Applikation für alle Benutzer zur Verfügung. Wir deaktivieren somit die Zuweisung für einzelne Benutzer komplett:

Assignment required = No

Screenshot Zuweisung einzelner Gruppen und Nutzer
Falls eine Zuweisung an einzelne Benutzer erwünscht ist, einfach „Assignment required“ auf „Yes“ umstellen (Standardeinstellung) und die Zuweisung für Benutzer unter „Users and Groups“ durchführen.

Konfiguration des AAA Servers / SAML SPs auf dem ADC

Um eine Applikation auf dem Netscaler mit einer Preauthentication zu schützen, kommt die AAA Funktion zum Einsatz. Hierfür wird ein AAA Virtual Server Objekt angelegt, welches in der SAML Welt gleichzeitig den SAML Service Provider (SP) darstellt, der in unserem Fall dem Microsoft Azure Identity Provider (IdP) vertraut. Um für eine Web Applikation die Anmeldung am AAA bzw. dem SAML IdP zu erzwingen, wird der AAA Vserver auf dem enstprechenden Load Balancer oder Content Switch Objekt über die „Authentication“ Registerkarte verknüpft.

Anlage des AAA Virtual Servers

Screenshot  Anlage des AAA im Authentication Virtual Servers
add authentication vserver aaademo SSL 0.0.0.0

Ein SSL Zertifikat muss gebunden werden, auch wenn der AAA Vserver nicht direkt angesprochen wird.

bind ssl vserver aaademo -certkeyName AAA_test
bind ssl vserver aaademo -eccCurveName P_256
bind ssl vserver aaademo -eccCurveName P_384
bind ssl vserver aaademo -eccCurveName P_224
bind ssl vserver aaademo -eccCurveName P_521

Screenshot SSL Virtual Server Server Certificate Binding

SAML SP Server

Falls der Import der Metadaten nicht funktioniert, können die Daten auch aus dem XML extrahiert werden und manuell hinterlegt werden. Das IdP Zertifikat lässt sich auf der Azure Enterprise Appliacation im Azure Portal exportieren (Base64 bietet sich an).

Screenshot mögliche Konfiguration aus dem Configure Authentication SAML Server
SAML Action 1/3
SAML Action 2/3

Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide):

SAML Action 3/3 – Relaystate Regel
add authentication samlAction AzureSSOHapp-SAMLServer -samlIdPCertName ADC-SAML-Connector -samlRedirectUrl "https://login.microsoftonline.com/883dfdf-154e-4fdf33-b857-1dfdf8d/saml2" -samlIssuerName "https://vipdemo.michael-wessel.de" -relaystateRule "AAA.LOGIN.RELAYSTATE.EQ(\"https://vipdemo.michael-wessel.de/\")" -logoutURL "https://login.microsoftonline.com/8dda6db-dde-4e33-dddd7-173179eb1e8d/saml2"

SAML SP Policy

Screenshot Configure Authentication Policy
add authentication Policy pol_AzureSSOHapp -rule true -action AzureSSOHapp-SAMLServer

Die erstellte SAML SP Policy muss dann an den AAA Virtual Server / SAML SP gebunden werden und der AAA Virtual Server auf der Registerkarte „Authentication“ des Load Balancers oder Content Switches verknüpft werden. Auf ADCs mit einer aktuellen Firmware haben sich zudem die Defaults für die Athorization geändert, so dass eine pasende Authorization Policy anzulegen ist.

Ausblick

Mit dem Vorliegen der Anmeldeinformationen kann auf dem Netscaler auch eine detaillierte Berechtigung auf bestimmte URLs anhand von z.B. Gruppenmitgliedschaften über Authorization Policies erfolgen.

Außerdem ist es möglich authentifizierte Benutzer z.B. per SAML oder KCD an Servern hinter der Pre-Authentication automatisch anzumelden.

Im MS Azure sind umfangreiche Möglichkeiten der Multi Faktor Authentifizierung und des Conditional Access möglich.

Mehr zu diesen und anderen Möglichkeiten werden sie in den weiteren Artikeln unserer Serie „verSAMLt“ lesen.

VMware vSphere: Kritische Sicherheitslücke im vCenter

Kürzlich gab VMware bekannt, dass es eine Sicherheitslücke in den Plugins des vCenter Servers bekanntgeworden ist (CVE-2021-21985). Betroffen hiervon sind die folgenden vCenter Versionen:

  • VMware vSphere 6.5
  • VMware vSphere 6.7
  • VMware vSphere 7.0
  • VMware Cloud Foundation Versionen 3.x und 4.x

Ohne Gegenmaßnahmen ist es Angreifern möglich, über das vSAN Health Plugin (Siehe Link) des vSphere Clients (HTML5) Schadcode in das System zu übertragen und Root-Rechte zu erlangen. Diese Sicherheitslücke betrifft auch Kunden, die kein vSAN im Einsatz haben, denn das Plugin ist standardmäßig installiert und aktiviert. Um diese Sicherheitslücke zu schließen hat VMware für die betroffenen vCenter-Versionen jeweils ein Update für den vCenter-Server bereitgestellt. In diesem wird gleichzeitig auch eine weitere Sicherheitslücke (CVE-2021-21986) geschlossen. Diese wurde seitens VMware hingegen als moderat gefährlich bezeichnet und ist im verlinkten KB-Artikel ebenfalls aufgeführt.

Response-Matrix der betroffenen Versionen

ProduktVersionCVE IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
vCenter Server 7.0CVE-2021-219859.8Kritisch 7.0 U2bKB83829FAQ
vCenter Server6.7CVE-2021-219859.8Kritisch 6.7 U3nKB83829FAQ
vCenter Server6.5CVE-2021-219859.8Kritisch 6.5 U3pKB83829FAQ
VMware vCenter Response-Matrix für CVE-2021-21985
ProduktVersionCVE-IdentifierCVSSv3EinstufungBehoben ab VersionWorkaroundsDokumentation
Cloud Foundation (vCenter Server) 4.xCVE-2021-219859.8Kritisch 4.2.1KB83829FAQ
Cloud Foundation (vCenter Server) 3.xCVE-2021-219859.8Kritisch 3.10.2.1KB83829FAQ
VMware vCenter Cloud Federation Response-Matrix für CVE-2021-21985

Möglicher Workaround (nur ohne aktives vSAN möglich)

Falls es nicht möglich sein sollte, das Update kurzfristig einzuspielen, gibt es einen Workaround, der in dem VMware KB-Artikel 83829 beschrieben wird. Dieser sieht vor in den betroffenen vCenter Versionen das schadhafte Plugin in den Dateien

/etc/vmware/vsphere-ui/compatibility-matrix.xml

bzw.

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

über einen Editor zu deaktivieren. Dies funktioniert allerdings nur, wenn Sie kein VMware vSAN im Einsatz haben.

Sollten Sie noch Fragen zum Schließen der Sicherheitslücke haben oder Unterstützung bei der der Umsetzung benötigen, sind wir gerne behilflich. Kontaktieren Sie gerne kurzfristig unseren Servicedesk oder Ihren Account Manager.

Weiterführende Informationen

https://www.vmware.com/security/advisories/VMSA-2021-0010.html
https://kb.vmware.com/s/article/83829
https://blogs.vmware.com/vsphere/2021/05/vmsa-2021-0010.html

Nach Hafnium ist vor…??? – Zeit für mehr Sicherheit mit Azure Sentinel

Durch die fortschreitende Digitalisierung und die immer steigende Komplexität der Informationstechnologie müssen auch die Administratoren sich immer wieder neuen Herausforderungen stellen. Die Daten der Unternehmen müssen vor fortschrittlicheren Cyber-Bedrohungen oder Schwachstellen in der eingesetzten Software (z.B. Exchange-Server und der HAFNIUM-Exploit vor kurzer Zeit) weiter fachkundig geschützt werden. Bei Problemen oder Sicherheitsvorfällen müssen in großen Mengen Logdaten gesichert und gesichtet werden. Meist war an dieser Stelle aber schon alles zu spät, die Administratoren im reaktiven Arbeits-Modus. Die Auswertungen nehmen Wochen oder Monate in Anspruch. Daher ist es in der heutigen Zeit noch wichtiger geworden, die Sicherheit der IT-Infrastruktur proaktiv im Blick zu behalten. Aber wie?

Im diesem Blog-Beitrag wollen wir eine Möglichkeit vorstellen, mit der diese reaktive Arbeit auf relativ einfache Art und Weise weitestgehend automatisiert werden kann: Azure Sentinel – der Cloud-basierten SIEM (Security Information Event Management)- und SOAR (Security Orchestration Automated Response)-Lösung von Microsoft.

Azure Sentinel wird von Microsoft seit 2019 angeboten und als Dienst innerhalb der Azure-Plattform betrieben. Auf dieser Basis ist mit einem aktiven Azure-Konto die schnelle Installation und der einfache Betrieb der Lösung möglich. Weitere Investitionen in Hard- und/oder Software sind nicht nötig. Die Abrechnung der genutzten Ressourcen (z.B. Log-Speicherplatz etc.) erfolgt, wie in Azure gewohnt, entweder nutzungsbasiert oder auf Basis von zuvor festgelegten Kontingenten.

Für die grundsätzliche Funktion sammelt und aggregiert die SIEM-Komponente fortwährend Logdaten, die in der gesamten IT-Infrastruktur des Unternehmens generiert werden. Dabei spielt es keine Rolle, ob die Daten von Systemen und Anwendungen aus der Cloud (auch Clouds anderer Anbieter) oder der lokalen Infrastruktur erzeugt und Azure Sentinel zugeführt werden. Mit den dafür genutzten Monitoring-Agenten auf Linux- oder Windows-Servern können auf gleichem Wege die Logdaten von Netzwerk- und Sicherheitsgeräten wie Firewalls oder dem Endpoint-Schutz gesammelt werden. Innerhalb dieser Datenmenge werden über Analyse-Regeln sicherheitskritische Vorfälle und Ereignisse identifiziert, kategorisiert und analysiert. Für die Erkennung werden unter anderem auch die im Mitre ATT&CK-Framework (https://attack.mitre.org/matrices/enterprise/) aufgeführten Angriffs-Taktiken und -Techniken genutzt. Erkannte Bedrohungen, Anomalien oder Angriffe werden automatisch innerhalb von Azure Sentinel als Incidents angelegt und damit zum weiteren Handeln der IT-Administration übergeben. Diese Administratoren können nun über die erstellten Incidents auf umfangreiche Details der Vorfälle zurückgreifen. Hier werden die beteiligten Objekte im Einzelnen aufgeführt und zusätzlich in einer Übersichtgrafik dargestellt, so dass Zusammenhänge schnell erfasst werden können.

In der Praxis bietet Azure Sentinel dafür schon von Haus aus eine Vielzahl von vorkonfigurierten oder individuell anpassbaren Daten-Konnektoren, mit denen auf einfache Weise die nötigen Daten strukturiert gesammelt werden können. Viele Konnektoren haben dieselben Datenquellen, so dass z.B. im Bereich der Server nur ein zu installierender Monitoring-Agent auf Windows- oder Linux-Systemen unterschiedliche Daten sammelt – egal ob sie in der Cloud oder lokal betrieben werden.

Azure Sentinel bietet aber standardmäßig nicht nur die Daten-Konnektoren an, sondern auch weitere Bausteine:

  • Analyseregel-Vorlagen zum Auswerten der Logdaten mit intelligenten KI-Algorithmen und maschinellem Lernen
  • Arbeitsmappen zur Visualisierung der Logdaten
  • Thread-Hunting-Regeln zur aktiven Suche von Sicherheitsbedrohungen
  • Analyse des Benutzer- und Entity-Verhaltens für zuverlässige, handlungsrelevante Informationen zu den Vorfällen

Um dann aber auch automatisiert auf die durch SIEM erkannten Sicherheitsbedrohungen zu reagieren geht die SOAR-Komponente einen weiteren Schritt: Azure Sentinel bietet dafür die sogenannten Playbooks an. Durch die bereits integrierten Konnektoren zu unterschiedlichen externen Systemen könne über Trigger und Aktionen auch komplexere Szenarien abgebildet werden, wenn durch SIEM ein Vorfall gemeldet wird. Hier z.B. eine Reaktion auf einen eventuell kompromittierten Benutzer:

Dieser Beitrag kann nur einen groben Überblick über das breite Leistungsspektrum von Azure Sentinel liefern. Haben wir Ihr Interesse für diesen zusätzlichen, proaktiven Schutz Ihrer IT geweckt? Dann sprechen Sie uns gerne für weitere Informationen oder eine Live-Demo in Azure Sentinel an. Gehört Microsoft 365 / Microsoft Azure bereits zu Ihrer IT-Infrastruktur, dann bieten wir Ihnen gerne auch einen individuellen Proof-of-concept direkt in Ihrer IT-Umgebung an.

Microsoft füllt Vakuum nach Privacy Shield

Wie in meinem letzten Beitrag angekündigt hat Microsoft in Sachen „Standardvertragsklauseln“ nachgesorgt: die Erweiterung des Data Protection Agreements ist in Kürze fertig für den deutschen Markt. Dort enthalten sein werden Änderungen, die den Schutz der Kundendaten noch deutlicher in den Mittelpunkt stellen und die das durch das EuGH-Urteil (Schrems II) entstandene Vakuum füllen:

  • Microsoft verpflichtet sich, jede Auskunftsanfrage einer Regierung (egal welcher) mit allen rechtlichen Mitteln anzufechten.
  • Im Fall einer gesetzmäßigen Auslieferung von Daten nach allen rechtlichen Instanzen sichert Microsoft den betroffenen Kunden Entschädigungszahlungen zu.

Mit diesen und weiteren Regelungen geht Microsoft über die Anforderungen und Empfehlungen des Europäischen Datenschutzausschusses hinaus.

Ein Facebook User kippt Privacy Shield – und jetzt?

Privacy Shield bezeichnet die (Selbst-)Verpflichtung zur Einhaltung von Datenschutzstandards in den USA, die dem europäischen Datenschutzrecht genügen (Stichwort DSGVO). Unter diesem Schutzschirm konnten europäische Unternehmen DSGVO-konform Daten an Auftragsverarbeiter mit Sitz in den USA weitergeben, die sich nach EU-US Privacy Shield zertifiziert hatten.

Schutzschild zerschlagen

Kürzlich ist diese Praxis vom EuGH für ungültig erklärt worden („Schrems II“-Urteil vom 16. Juli 2020). Max Schrems, österreichischer Jurist und Datenschutzaktivist hatte mit seiner Klage vor dem EuGH schon für das Kippen des Privacy Shield Vorgängers, dem Safe-Harbor-Abkommen, gesorgt. Hintergrund ist die Praxis von Facebook, auch die Daten europäischer Nutzer nicht an seinem Standort in Irland oder andernorts auf europäischem Boden zu verarbeiten, sondern allesamt auch ungefragt in die USA zu transferieren. Diese Praxis für seine personenbezogenen Daten nahm Schrems zum Anlass seiner Klage. Spätestens seit den Enthüllungen von Edward Snowden ist bekannt, dass US-Unternehmen sich nicht an die Zusicherungen von Privacy Shield halten oder halten können, wenn US-Geheimdienste (und ihre Partner) etwas wissen wollen. Es gibt sogar konkrete US-Gesetze, die eine Massenüberwachung vorschreiben (z.B. FISA 702 und EO 12.333). Dies steht in vollkommenem Gegensatz zur europäischen Datenschutzgrundverordnung DSGVO.

Was nun?

Wer IT-Dienste in seinem Unternehmen nutzt, hat mit hoher Wahrscheinlichkeit Berührungspunkte zu dieser Problemstellung. Es fängt schon bei der öffentlichen Website an: welche Dienste werden genutzt, welche Fonts, welche Cookies von welchen Anbietern übertragen Informationen der Besucher in die USA? Haben Sie sich mal die Liste von Diensten und Cookies angeschaut, die Sie beim Besuch einer Website akzeptieren sollen?

Ihre eigene oder auch andere Websites können Sie mit Blacklight scannen, um einen Eindruck zu bekommen. Als kommerzieller Dienst bietet Cookiebot noch Mehrwerte. Dieser Artikel von Cookiebot diente auch als eine der Quellen für diesen Beitrag.

Für den Geschäftsbetrieb noch kritischer sind aber SaaS Dienste wie Office 365, Salesforce und viele andere, die heute omnipräsent auch in europäischen Unternehmen sind. Was gilt es hier nun zu beachten?

SaaS weiter nutzen

Stellen Sie vor allem sicher, dass Sie die von den Anbietern fast immer bereitgestellten „Standardvertragsklauseln“ abgeschlossen haben. Damit gehen Kunden eine direkte Vertragsbeziehung mit dem Anbieter ein, in der der Anbieter den Datenschutz zusichert. Diese Praxis wurde vom EuGH ebenfalls geprüft und für weiterhin geeignet befunden, ein adäquates Datenschutzniveau zu gewährleisten. Wohlgemerkt: der Mechanismus ist in Ordnung – die Standardvertragsklauseln einiger Anbieter müssen und werden inhaltlich voraussichtlich kurzfristig nachgebessert werden.

Bei Office 365 sollten Sie in jedem Fall darauf achten, dass der Datenspeicherort für Ihre Organisation auf Europa oder sogar Deutschland festgelegt ist:

Risiken bewerten

Datenschutzbeauftragte neigen dazu, auf „Nummer sicher“ zu gehen und lieber von der Nutzung abzuraten. Diese Haltung sollte differenziert hinterfragt und diskutiert werden. Neben den nicht ganz klar greifbaren Risiken, Dienste weiter zu nutzen auch unter vorübergehend nicht vollkommen belastbaren Standardvertragsklauseln, sind die Risiken, sich ganz akut in Teilen handlungsunfähig zu machen, wahrscheinlich größer.

Haftung

Wir können keine rechtliche Beratung zu diesem Thema anbieten, sondern stellen diese Informationen als Hinweise und Tipps zur Verfügung. Eine juristisch fundiertere Analyse – und natürlich auch Angebote zur Beratung – finden Sie zum Beispiel bei der audatis in Herford und Potsdam.

Outlook Mobile: Microsoft sendet Mitteilungen an Outlook-User

Microsoft aktualisiert die Ankündigung „Benachrichtigung über Outlook Mobile in Outlook“ (MC207028) und erweitert das Gebiet auch auf Europa.

Seit dem 12. August 2020 informiert Microsoft an Outlook Benutzer, die noch kein Outlook Mobile nutzen, darüber das es Outlook auch für iOS und Android gibt.

Außerdem befindet sich in dieser Benachrichtigung ein Link, über den sich der Nutzer komfortabel die Outlook Mobile App für Android oder iOS Herunterladen können bzw. wird hier auf die entsprechende App Stores der beiden Plattformen verwiesen.

Wird diese Benachrichtigung geschlossen oder der Benutzer installiert sich Outlook Mobile, erscheint keine erneute Benachrichtigung.
Jedoch kann die Benachrichtigung auch zentral administrativ über ein entsprechendes cmdlet in Powershell deaktiviert werden.

Sollten Sie diese Nachrichten bei Ihnen und ihren Nutzern nicht wünschen, können wir sie dabei gerne unterstützen.

Wenden Sie sich daher gerne vertrauensvoll an uns.

Von gestern auf heute – unternehmensweit Home Office für alle

Über den Anlass ist eigentlich genug gesagt; SARS-CoV-2 und die von ihm ausgelöste Erkrankung COVID-19 beschleunigt aktuell die Entwicklung von Lösungen zum verteilten Arbeiten enorm. In Anbetracht der zunächst zögerlich, nun schrittweise entschlossener getroffenen Maßnahmen, mit denen die Kontaktfrequenz von Menschen reduziert wird, haben auch wir konkret gehandelt.

Home Office für alle

Es geht um jeden und jede Einzelne, vor allem aber um den Schutz des gesamten Gesundheitssystems vor einem zu schnellen Ausbruch in der Breite. Was wir als Unternehmen tun können: unsere Mitarbeiter schützen und damit auch die Ausbreitung des Virus insgesamt verlangsamen, um die wirklich gefährdeten Risikogruppen zu schützen. Mit diesem Ziel haben wir kurzfristig entschieden, allen Mitarbeiter*innen das Arbeiten aus dem Home Office zu ermöglichen und zu empfehlen.

Leichter gesagt als getan

Nun sollte man meinen, dass für ein Technologie-nahes Unternehmen das relativ einfach sein sollte. Für weite Teile der Mitarbeiterschaft trifft das auch zu und erforderte keinerlei (technische) Aktivität. Entscheidend dabei war, dass wir mit sehr großen Teilen unseres Tagesgeschäftes bereits in der Cloud sind (Microsoft Teams).

Bei genauerer Betrachtung fielen uns aber unmittelbar Arbeitsprofile und -schritte auf, die noch nicht abgedeckt waren. Zumindest nicht in der Skalierung „für alle“. Auch für diese Zwecke konnten Lösungen oder Alternativen gefunden werden, jedoch ein einfaches Schalterumlegen ist dieser Schritt nicht. Für viele Unternehmen werden außerdem noch größere organisatorische Klärungen und Regelungen erforderlich sein. Auch bei uns tauchten schnell Fragen nach der Handhabung von Besucherempfang, Warenannahme u.ä. auf, die zu lösen sind. Je mehr Arbeitsprozesse bereits digitalisiert sind, desto besser.

Erfolgreich verteilt arbeiten

Manche Unternehmen, insbesondere die Vertriebsorganisationen vieler Hersteller im IT-Sektor, arbeiten seit jeher verteilt. Alle Mitarbeiter haben ein Home Office, es gibt wenig bis kaum Präsenz-Meetings. Und diese Organisationen arbeiten effizient und erfolgreich. Eine Umstellung auf dieses Modell ist aber nicht so einfach wie

  • technische Möglichkeiten realisieren
  • arbeitsrechtliche Grundlagen schaffen
  • organisatorisch entscheiden und umsetzen

sondern erfordert auch eine individuelle Entwicklung der Mitarbeiter. Wie auch bei der grundsätzlichen Einführung moderner Zusammenarbeit müssen Organisation und Menschen lernen und sich entwickeln. Daher ist die technische Bereitstellung nur ein Baustein. In der aktuellen Lage kann dieser Schritt definitiv schnell hilfreich sein und sollte nicht gänzlich aufgehalten werden. Jedoch müssen Sie im Auge behalten, dass im Nachgang noch viel Arbeit zu leisten ist, um dauerhaft erfolgreich anders zu arbeiten – erfolgreicher als zuvor. In der Zwischenzeit geht es darum, überhaupt produktiv sein zu können, während äußere Zwänge das „normale“ Arbeiten verhindern.

Erste sehr gute Tipps lassen sich etwa den Empfehlungen der Personalchefin von Microsoft Deutschland entnehmen. Individuelle Lösungen für Ihr Unternehmen erarbeiten wir gerne gemeinsam mit Ihnen.

CDC Germany 2020: Nils Kaczenski erneut als Sprecher dabei

imageDie Kuratoren der Cloud & Datacenter Conference Germany (CDC) haben es in diesem Jahr besonders spannend gemacht. Nun ist es aber bestätigt: Erneut wird unser Consulting-Leiter Nils Kaczenski als Speaker bei der Konferenz dabei sein.

Bereits zum fünften Mal lädt die Community-Konferenz die IT-Branche zu einem hochkarätigen Event, das in Deutschland seinesgleichen sucht. An zwei Tagen – dem 13. und 14. Mai 2020 – wird ein Feld von über 30 bekannten IT-Experten mehr als 50 Fachvorträge in vier parallelen Tracks halten. Das Lineup liest sich dabei wie ein “Who is who” der europäischen IT-Community, auch Speaker aus Übersee sind dabei.

Die Resonanz der Besucher war in den vergangenen Jahren überwältigend. Dazu tragen auch die hervorragende Location in Hanau sowie die liebevolle Organisation bei, die bei aller Professionalität dem Event einen fast familiären Charakter gibt.

Details und die Anmeldung finden sich hier:

[Cloud & Datacenter Conference Germany: Die Zukunft Ihrer IT gestalten]
https://www.cdc-germany.de/