IAM-User und dazugehörige Access-Key-ID und Secret-Access-Key werden noch immer häufig verwendet, um den programmatischen Zugang zur Cloud von Amazon Web Services (AWS) zu ermöglichen. Diese meist langlebigen Credentials stellen jedoch durchaus ein Sicherheitsrisiko dar. Die deutlich sicherere Alternative wird immer noch nicht flächendeckend verwendet. Wir wollen uns in diesem Artikel diese Alternative mal anschauen und besprechen, wann diese sinnvoll ist.
Wer vor einigen Jahren angefangen hat, mit der Cloud von Amazon Web Services (AWS) zu arbeiten, kennt zwangsläufig die Kombination aus Access-Key-ID und Secret-Access-Key, die für einen IAM-User erzeugt werden kann. Mithilfe dieser Credentials wird der programmatische Zugriff auf die AWS-Cloud ermöglicht, um so Cloud-Ressourcen verwenden und verwalten zu können. Alles, was sich über die Web-Oberfläche verwalten lässt, kann so auch programmatisch aus Programmiersprachen wie Java und Co. heraus durchgeführt werden.
Anders als das Passwort für die Weboberfläche, das idealerweise nur in den Köpfen des Anwenders lebt, liegen Access-Key-ID und Secret-Access-Key meist irgendwo auf der Festplatte, in einem Slack/Teams-Channel oder als Secret im CI/CD-System rum. Nicht selten genug, lassen sich die Credentials auch in Build-Artefakten wie JARs oder ähnlichem wiederfinden. Es wird also in Summe doch recht stiefmütterlich mit diesen Credentials umgegangen. Das ist tatsächlich durchaus problematisch, da diese effektiv gleichbedeutend mit einem Passwort sind. Oft hängen auch noch deutlich zu viele Rechte an dem IAM-Users und den dazugehörigen Credentials. Eine mitunter sehr gefährliche Mischung, die ein großes Sicherheitsrisiko darstellt.
Dennoch ist der unvorsichtige Umgang mit den Keys durchaus nachvollziehbar, denn dieser ermöglicht es, schnell mal was in der Cloud auszuprobieren. Einmal angelegt und mit notwendigen (und oft zu vielen) Rechten versehen, ist Zugriff auf die Cloud schnell eingerichtet. Leider auf Kosten der Sicherheit. Sobald die Credentials einmal in die falschen Hände geraten, ist – je nachdem wie viele Befugnisse vergeben wurden – die Anwendung oder gar die gesamte Anwendungslandschaft in Gefahr. Nicht verwunderlich also, dass Webseiten wie GitHub automatisiert nach solchen Keys scannen und bei einem Treffer sofort Alarm schlagen.
Während Access-Key-ID und Secret-Access-Key vielseitig einsetzbar sind, hängen mögliche Alternativen meist vom konkreten Anwendungsfall ab. Die drei häufigsten davon sind: die lokale Entwicklung von Cloud-basierten Anwendungen, das Deployment mithilfe des CI/CD-Systems und natürlich die produktiv laufende Anwendung selbst. Bei allen drei gestaltet sich der Zugriff durchaus unterschiedlich.
Bei der lokalen Entwicklung von Cloud-basierten Anwendung war es in der Vergangenheit nicht unüblich, dass für jeden Entwickler ein IAM-User in AWS angelegt wurde und die dazugehörigen Keys auf dessen Maschine abgelegt wurden. Seit ein paar Jahren können Benutzerkonten in AWS jedoch deutlich besser und meist sicherer durch AWS Identity Center (vormals auch bekannt als AWS SSO) verwaltet werden.
Für IAM-User gab es schon immer die Möglichkeit in verschiedene Rollen zu schlüpfen und somit auch unterschiedliche Rechte zu erhalten – das Ganze ist jedoch ein weitestgehender manueller Prozess, die von vielen vermieden wurde. Mit AWS Identity Center ist das Konzept von Rollen deutlich mehr im Fokus. Bevor ein Benutzer sich anmelden kann, muss dieser zunächst auswählen, mit welcher Rolle und den damit verbundenen Rechten dieser agieren möchte. Dies ist sowohl im Web-Browser als auch im Terminal möglich. Erfolgt die Anmeldung über das Terminal werden kurzfristige Anmeldedaten für die gewählte Rolle erzeugt und lokal als Token hinterlegt. Dieser ist meist nur für wenige Stunden gültig und ein Verlust stellt somit nur ein begrenztes Risiko dar. Um sich im Terminal anzumelden, kann das AWS CLI mit dem Befehl `aws sso configure` verwendet werden. Der Benutzer kann dort zwischen verschiedenen, zuvor durch einen Administrator eingerichteten, Rollen wählen. In OAuth2-Manier wird dann über den Browser das kurzlebige Token angelegt.
Das erzeugte Token kann dann von gängigen SDK genutzt werden, um in der gewählten Programmiersprache auf Cloud-Ressourcen in AWS zuzugreifen. Anders als beim klassischen Ansatz mit Access-Key-ID und Secret-Access-Key, muss der Entwickler sich lediglich in regelmäßigen Abständen neu anmelden, um einen neuen Token zu erhalten. Das Risiko, dass sicherheitskritische Informationen abhanden gehen, ist somit deutlich reduziert. Gleichzeitig bietet die Nutzung von AWS Identity Center dem Entwickler eine einfache Möglichkeit, bewusst nur die Rechte in Anspruch zu nehmen, welche für die lokale Entwicklung aktuell benötigt werden. Da die gängigen AWS-SDKs verschiedene Strategien haben, auf die Cloud zuzugreifen, müssen im Code auch keinerlei Änderungen erfolgen, um von Keys zum Token-basierten Ansatz zu wechseln.
Zu Zeiten von automatisierten Deployments brauchen nicht nur die Entwickler Zugriff auf die Cloud, sondern eben auch technische User wie etwa das CI/CD-System. Auch hier kamen üblicherweise dedizierte IAM-User inklusive des Access-Key-ID und Secret-Access-Key zum Einsatz und wurden entsprechend so als Secret hinterlegt, dass das CI/CD-System auf die Cloud zugreifen kann. Ähnlich wie auch bei der lokalen Entwicklung stellen solche langlebigen Keys ein erhöhtes Sicherheitsrisiko dar.
In gängigen CI/CD-Systemen lässt sich jedoch mithilfe von Open ID Connect (OICD) der Spieß gewissermaßen umdrehen. Statt die Credentials eines IAM-Users als Secret zu hinterlegen, meldet sich das CI/CD-System bei AWS und lässt sich bei Erfolg einen kurzlebigen Token ausstellen.
Um dies zu ermöglichen, wird der Account in AWS so konfiguriert, dass z.B. ein bestimmtes GitHub-Projekt auf Anfrage die angegebenen Rechte durch den übergebenen Token erhält. In GitHub Actions kann dieser Token dann verwendet werden, um auf die Cloud-Ressourcen in AWS zuzugreifen und dann etwa eine Anwendung bereitzustellen. Durch die Verwendung asymmetrischer Kryptografie müssen keine geheimen Daten an Drittsysteme übergeben werden. Dieser Ansatz basiert stattdessen weitestgehend auf Vertrauen gegenüber dem eingesetzten CI/CD-System.
Nahezu jedes moderne CI/CD-System bietet inzwischen die Möglichkeit mithilfe von OpenID Connect auf sichere Weise kurzlebige Token für den Zugriff auf die meisten Cloud-Anbieter, also nicht nur AWS, zu erstellen. Bei der Konfiguration bedarf es dabei letztlich zwei Schritten. Zunächst wird auf Seite des Cloud-Anbieters festgelegt, welches CI/CD-System und vor allem auch welches Projekt Zugriff erhalten darf. Die benötigten Informationen hängen dabei vom CI/CD-System ab. Für GitHub werden insbesondere Organisation/User, das eigentliche Git-Repository sowie optional der Branch-Name benötigt. Eine IAM-Rolle mit den benötigten Rechten kann anhand dieser Information auf die Benutzung in GitHub eingeschränkt werden (siehe dazu Listing 1).
Danach muss das CI/CD-System so konfiguriert werden, dass es einen entsprechenden ID-Token im Sinne von Open ID Connect erzeugt und mit diesem beim Cloud-Anbieter die zuvor festgelegten Rechte anfordert. Wie genau das funktioniert, hängt sowohl vom Cloud-Anbieter als auch vom CI/CD-System ab. Ein Beispiel, wie die Umsetzung in GitHub Actions erfolgen könnte, zeigt Listing 2.
Auch beim produktiven Deployment stellt sich die Frage, wie der Anwendung ermöglicht wird, auf die Cloud zuzugreifen. Insbesondere dann, wenn die Anwendung nicht nur Cloud-Services verwendet, sondern eben auch auf Maschinen in selbiger bereitgestellt wird, gibt es auch hier deutlich bessere Wege als die direkte Verwendung von Access-Key-ID und Secret-Access-Key. Statt die Keys via Konfiguration in die Anwendung einzureichen (oder schlimmer noch: einzubetten) lässt sich das Problem des Zugriffs besser auf infrastruktureller Ebene lösen.
Statt die Rechte der Anwendung direkt zuzuteilen, werden diese der Maschine übergeben. Die Anwendung kann dann quasi die der Maschine zugeteilten Rechte übernehmen. In AWS können EC2-Maschinen, aber auch anderen Ausführungumgebungen, wie etwa AWS Lambda, Rollen und somit Rechte zugewiesen werden. AWS SDKs in gängigen Programmiersprachen erkennen dann, dass sie etwa innerhalb einer EC2-Maschine ausgeführt werden und bedienen sich dann automatisch den Rechten der angehängten Rollen.
Wie auch bei der lokalen Entwicklung passiert dies ohne jegliche Anpassung der Anwendung. Dieser ist effektiv, egal, ob Zugriff auf die Cloud durch AWS Identity Center oder eben durch eine anhängige Rolle in einer EC2-Maschine ermöglicht wird. Im Hintergrund verwendet das AWS SDK ähnlich wie auf der lokalen Maschine oder im CI/CD-System zudem kurzlebige Berechtigungen. Selbst bei einer komprimierten Anwendung oder ganzen Maschine, sind daher die Auswirkungen bezüglich Sicherheit deutlich überschaubarer.
Nur weil Dinge immer schon so gemacht wurden, heißt das nicht, dass es gut sein muss. So auch bei der noch allzu oft Verwendung von Secret-Access-Key und eigentlich auch IAM-User im Allgemeinen. Inzwischen gibt es für nahezu alle anderen Anwendungsfälle eine bessere Lösung, bei der eben nicht mit sicherheitskritischen Credentials rumhantiert werden müssen. Selbst für den hier nicht besprochenen Fall, dass eine Anwendung die Cloud nutzt, aber nicht in dieser bereitgestellt wird, gibt es heute auch gute Lösungen wie etwa HashiCorps Vault. Mehr Security muss also durchaus nicht viel mehr Aufwand benötigen. So ist die Verwendung von AWS Identity Center nicht nur sicherer, sondern auch für alle Beteiligten auch deutlich angenehmer. Nicht nur bei Security, kann es sich durchaus mal lohnen, das aktuelle Vorgehen zu hinterfragen und mit der aktuellen Best Practice abzugleichen.
In den kommenden Wochen und Monaten erscheinen weitere Artikel zum Thema Cloud.
Was ist eigentlich aus Serverless geworden?
Low-Level- und High-Level-Cloud
Der Artikel ist Teil der IT Spektrum 05/23 S. 48
Die Vorschau des Magazins ist hier zu finden.
Wer vor einigen Jahren angefangen hat, mit der Cloud von Amazon Web Services (AWS) zu arbeiten, kennt zwangsläufig die Kombination aus Access-Key-ID und Secret-Access-Key, die für einen IAM-User erzeugt werden kann. Mithilfe dieser Credentials wird der programmatische Zugriff auf die AWS-Cloud ermöglicht, um so Cloud-Ressourcen verwenden und verwalten zu können. Alles, was sich über die Web-Oberfläche verwalten lässt, kann so auch programmatisch aus Programmiersprachen wie Java und Co. heraus durchgeführt werden.
Anders als das Passwort für die Weboberfläche, das idealerweise nur in den Köpfen des Anwenders lebt, liegen Access-Key-ID und Secret-Access-Key meist irgendwo auf der Festplatte, in einem Slack/Teams-Channel oder als Secret im CI/CD-System rum. Nicht selten genug, lassen sich die Credentials auch in Build-Artefakten wie JARs oder ähnlichem wiederfinden. Es wird also in Summe doch recht stiefmütterlich mit diesen Credentials umgegangen. Das ist tatsächlich durchaus problematisch, da diese effektiv gleichbedeutend mit einem Passwort sind. Oft hängen auch noch deutlich zu viele Rechte an dem IAM-Users und den dazugehörigen Credentials. Eine mitunter sehr gefährliche Mischung, die ein großes Sicherheitsrisiko darstellt.
Dennoch ist der unvorsichtige Umgang mit den Keys durchaus nachvollziehbar, denn dieser ermöglicht es, schnell mal was in der Cloud auszuprobieren. Einmal angelegt und mit notwendigen (und oft zu vielen) Rechten versehen, ist Zugriff auf die Cloud schnell eingerichtet. Leider auf Kosten der Sicherheit. Sobald die Credentials einmal in die falschen Hände geraten, ist – je nachdem wie viele Befugnisse vergeben wurden – die Anwendung oder gar die gesamte Anwendungslandschaft in Gefahr. Nicht verwunderlich also, dass Webseiten wie GitHub automatisiert nach solchen Keys scannen und bei einem Treffer sofort Alarm schlagen.
Während Access-Key-ID und Secret-Access-Key vielseitig einsetzbar sind, hängen mögliche Alternativen meist vom konkreten Anwendungsfall ab. Die drei häufigsten davon sind: die lokale Entwicklung von Cloud-basierten Anwendungen, das Deployment mithilfe des CI/CD-Systems und natürlich die produktiv laufende Anwendung selbst. Bei allen drei gestaltet sich der Zugriff durchaus unterschiedlich.
Bei der lokalen Entwicklung von Cloud-basierten Anwendung war es in der Vergangenheit nicht unüblich, dass für jeden Entwickler ein IAM-User in AWS angelegt wurde und die dazugehörigen Keys auf dessen Maschine abgelegt wurden. Seit ein paar Jahren können Benutzerkonten in AWS jedoch deutlich besser und meist sicherer durch AWS Identity Center (vormals auch bekannt als AWS SSO) verwaltet werden.
Für IAM-User gab es schon immer die Möglichkeit in verschiedene Rollen zu schlüpfen und somit auch unterschiedliche Rechte zu erhalten – das Ganze ist jedoch ein weitestgehender manueller Prozess, die von vielen vermieden wurde. Mit AWS Identity Center ist das Konzept von Rollen deutlich mehr im Fokus. Bevor ein Benutzer sich anmelden kann, muss dieser zunächst auswählen, mit welcher Rolle und den damit verbundenen Rechten dieser agieren möchte. Dies ist sowohl im Web-Browser als auch im Terminal möglich. Erfolgt die Anmeldung über das Terminal werden kurzfristige Anmeldedaten für die gewählte Rolle erzeugt und lokal als Token hinterlegt. Dieser ist meist nur für wenige Stunden gültig und ein Verlust stellt somit nur ein begrenztes Risiko dar. Um sich im Terminal anzumelden, kann das AWS CLI mit dem Befehl `aws sso configure` verwendet werden. Der Benutzer kann dort zwischen verschiedenen, zuvor durch einen Administrator eingerichteten, Rollen wählen. In OAuth2-Manier wird dann über den Browser das kurzlebige Token angelegt.
Das erzeugte Token kann dann von gängigen SDK genutzt werden, um in der gewählten Programmiersprache auf Cloud-Ressourcen in AWS zuzugreifen. Anders als beim klassischen Ansatz mit Access-Key-ID und Secret-Access-Key, muss der Entwickler sich lediglich in regelmäßigen Abständen neu anmelden, um einen neuen Token zu erhalten. Das Risiko, dass sicherheitskritische Informationen abhanden gehen, ist somit deutlich reduziert. Gleichzeitig bietet die Nutzung von AWS Identity Center dem Entwickler eine einfache Möglichkeit, bewusst nur die Rechte in Anspruch zu nehmen, welche für die lokale Entwicklung aktuell benötigt werden. Da die gängigen AWS-SDKs verschiedene Strategien haben, auf die Cloud zuzugreifen, müssen im Code auch keinerlei Änderungen erfolgen, um von Keys zum Token-basierten Ansatz zu wechseln.
Zu Zeiten von automatisierten Deployments brauchen nicht nur die Entwickler Zugriff auf die Cloud, sondern eben auch technische User wie etwa das CI/CD-System. Auch hier kamen üblicherweise dedizierte IAM-User inklusive des Access-Key-ID und Secret-Access-Key zum Einsatz und wurden entsprechend so als Secret hinterlegt, dass das CI/CD-System auf die Cloud zugreifen kann. Ähnlich wie auch bei der lokalen Entwicklung stellen solche langlebigen Keys ein erhöhtes Sicherheitsrisiko dar.
In gängigen CI/CD-Systemen lässt sich jedoch mithilfe von Open ID Connect (OICD) der Spieß gewissermaßen umdrehen. Statt die Credentials eines IAM-Users als Secret zu hinterlegen, meldet sich das CI/CD-System bei AWS und lässt sich bei Erfolg einen kurzlebigen Token ausstellen.
Um dies zu ermöglichen, wird der Account in AWS so konfiguriert, dass z.B. ein bestimmtes GitHub-Projekt auf Anfrage die angegebenen Rechte durch den übergebenen Token erhält. In GitHub Actions kann dieser Token dann verwendet werden, um auf die Cloud-Ressourcen in AWS zuzugreifen und dann etwa eine Anwendung bereitzustellen. Durch die Verwendung asymmetrischer Kryptografie müssen keine geheimen Daten an Drittsysteme übergeben werden. Dieser Ansatz basiert stattdessen weitestgehend auf Vertrauen gegenüber dem eingesetzten CI/CD-System.
Nahezu jedes moderne CI/CD-System bietet inzwischen die Möglichkeit mithilfe von OpenID Connect auf sichere Weise kurzlebige Token für den Zugriff auf die meisten Cloud-Anbieter, also nicht nur AWS, zu erstellen. Bei der Konfiguration bedarf es dabei letztlich zwei Schritten. Zunächst wird auf Seite des Cloud-Anbieters festgelegt, welches CI/CD-System und vor allem auch welches Projekt Zugriff erhalten darf. Die benötigten Informationen hängen dabei vom CI/CD-System ab. Für GitHub werden insbesondere Organisation/User, das eigentliche Git-Repository sowie optional der Branch-Name benötigt. Eine IAM-Rolle mit den benötigten Rechten kann anhand dieser Information auf die Benutzung in GitHub eingeschränkt werden (siehe dazu Listing 1).
Danach muss das CI/CD-System so konfiguriert werden, dass es einen entsprechenden ID-Token im Sinne von Open ID Connect erzeugt und mit diesem beim Cloud-Anbieter die zuvor festgelegten Rechte anfordert. Wie genau das funktioniert, hängt sowohl vom Cloud-Anbieter als auch vom CI/CD-System ab. Ein Beispiel, wie die Umsetzung in GitHub Actions erfolgen könnte, zeigt Listing 2.
Auch beim produktiven Deployment stellt sich die Frage, wie der Anwendung ermöglicht wird, auf die Cloud zuzugreifen. Insbesondere dann, wenn die Anwendung nicht nur Cloud-Services verwendet, sondern eben auch auf Maschinen in selbiger bereitgestellt wird, gibt es auch hier deutlich bessere Wege als die direkte Verwendung von Access-Key-ID und Secret-Access-Key. Statt die Keys via Konfiguration in die Anwendung einzureichen (oder schlimmer noch: einzubetten) lässt sich das Problem des Zugriffs besser auf infrastruktureller Ebene lösen.
Statt die Rechte der Anwendung direkt zuzuteilen, werden diese der Maschine übergeben. Die Anwendung kann dann quasi die der Maschine zugeteilten Rechte übernehmen. In AWS können EC2-Maschinen, aber auch anderen Ausführungumgebungen, wie etwa AWS Lambda, Rollen und somit Rechte zugewiesen werden. AWS SDKs in gängigen Programmiersprachen erkennen dann, dass sie etwa innerhalb einer EC2-Maschine ausgeführt werden und bedienen sich dann automatisch den Rechten der angehängten Rollen.
Wie auch bei der lokalen Entwicklung passiert dies ohne jegliche Anpassung der Anwendung. Dieser ist effektiv, egal, ob Zugriff auf die Cloud durch AWS Identity Center oder eben durch eine anhängige Rolle in einer EC2-Maschine ermöglicht wird. Im Hintergrund verwendet das AWS SDK ähnlich wie auf der lokalen Maschine oder im CI/CD-System zudem kurzlebige Berechtigungen. Selbst bei einer komprimierten Anwendung oder ganzen Maschine, sind daher die Auswirkungen bezüglich Sicherheit deutlich überschaubarer.
Nur weil Dinge immer schon so gemacht wurden, heißt das nicht, dass es gut sein muss. So auch bei der noch allzu oft Verwendung von Secret-Access-Key und eigentlich auch IAM-User im Allgemeinen. Inzwischen gibt es für nahezu alle anderen Anwendungsfälle eine bessere Lösung, bei der eben nicht mit sicherheitskritischen Credentials rumhantiert werden müssen. Selbst für den hier nicht besprochenen Fall, dass eine Anwendung die Cloud nutzt, aber nicht in dieser bereitgestellt wird, gibt es heute auch gute Lösungen wie etwa HashiCorps Vault. Mehr Security muss also durchaus nicht viel mehr Aufwand benötigen. So ist die Verwendung von AWS Identity Center nicht nur sicherer, sondern auch für alle Beteiligten auch deutlich angenehmer. Nicht nur bei Security, kann es sich durchaus mal lohnen, das aktuelle Vorgehen zu hinterfragen und mit der aktuellen Best Practice abzugleichen.
In den kommenden Wochen und Monaten erscheinen weitere Artikel zum Thema Cloud.
Was ist eigentlich aus Serverless geworden?
Low-Level- und High-Level-Cloud
Der Artikel ist Teil der IT Spektrum 05/23 S. 48
Die Vorschau des Magazins ist hier zu finden.
