Cloud-Asset-Inventar
Ein Cloud-Asset-Inventar ist eine vollständige, kontinuierlich aktualisierte Aufzeichnung jeder Ressource, die eine Organisation betreibt - Compute-Instanzen, Speichervolumes, Netzwerke und DNS-Einträge - über jedes verbundene Cloud-Konto und jeden On-Premise-Server hinweg, einschließlich Ressourcen, die außerhalb offizieller Prozesse provisioniert wurden und die manuelle, punktuelle Audits routinemäßig übersehen.
Fragen Sie die meisten Infrastrukturteams nach einer vollständigen Liste dessen, was sie betreiben, und die Antwort ist eine Schätzung. Eine Wiki-Seite von vor achtzehn Monaten. Eine Tabelle, die jemand nebenbei pflegt. Der tatsächliche Bestand ist immer größer: eine Testinstanz, die ein Ingenieur für eine Demo hochgefahren und zu löschen vergessen hat, ein Storage-Bucket, der während eines Vorfalls vor drei Teams angelegt wurde, ein DNS-Eintrag, an dessen Ziel sich niemand mehr erinnert, ein ganzes Cloud-Konto, das während eines Hackathons mit einer privaten Karte eröffnet wurde. Nichts davon ist böswillig - so wächst Infrastruktur eben tatsächlich, eine Ad-hoc-Entscheidung nach der anderen, schneller als jemand sie dokumentiert. Ein Cloud-Asset-Inventar existiert, um genau diese Lücke zu schließen: kein Schnappschuss, den jemand aktualisiert, wenn er daran denkt, sondern eine lebendige, abfragbare Antwort auf „was haben wir eigentlich, gerade jetzt".
Ein nützliches Inventar deckt mehr als virtuelle Maschinen ab. Es verfolgt Speichervolumes und deren Anbindungsstatus, virtuelle Netzwerke samt der Subnetze und Routen darin, DNS-Zonen und Einträge, die auf möglicherweise nicht mehr existierende Ressourcen zeigen, sowie Sicherheitsgruppen oder Firewall-Regeln, die sich im Laufe der Zeit still ausweiten. Es umfasst jeden Provider, den eine Organisation nutzt, nicht nur den primären - die meisten mittelgroßen Infrastrukturbestände berühren mindestens zwei oder drei Clouds, plus eine Handvoll Bare-Metal- oder On-Premise-Server, die in keiner Cloud-Konsole überhaupt auftauchen. Genau in dieser Streuung verstecken sich typischerweise blinde Flecken wie die oben beschriebenen: Das Konto, an dessen Eröffnung sich niemand erinnert, liegt selten beim selben Provider wie alles andere. Und ein Inventar muss kontinuierlich bleiben, nicht periodisch - Infrastruktur ändert sich stündlich, sodass eine Liste, die sich nur zur Audit-Zeit aktualisiert, bereits veraltet ist, wenn sie jemand liest.
In der Praxis wird ein Inventar auf zwei Arten aufgebaut, oft kombiniert. Für Cloud-Konten fragt die Erkennung die eigene API jedes Providers ab, um aufzulisten, was existiert - Instanzen, Volumes, Netzwerke, DNS-Zonen - ohne irgendetwas auf den Ressourcen selbst zu installieren. Für physische Server und On-Premise-Infrastruktur, für die es keine Provider-API zum Abfragen gibt, stützt sich die Erkennung stattdessen auf einen leichtgewichtigen Agenten, der auf jedem Host läuft. Kein Ansatz erfordert eine Migration: Erkennung ist absichtlich nur lesend, eine Möglichkeit zu sehen, was da ist, bevor Sie entscheiden, was - wenn überhaupt - geändert werden soll. Die meisten Organisationen behandeln das Inventar danach als Ausgangspunkt statt als Endzustand - jede entdeckte Ressource ist ein Kandidat für aktive Verwaltung, Tagging oder Kostenverfolgung, einzeln aufgenommen statt alle auf einmal.
Warum ein Cloud-Asset-Inventar wichtig ist
Eine Lücke im Inventar ist ein blinder Fleck mit echten Konsequenzen. Ein Server, von dem niemand weiß, dass er existiert, ist ein Server, den niemand patcht - und ungepatchte, vergessene Infrastruktur ist überproportional oft die Quelle von Sicherheitsvorfällen, gerade weil sie außerhalb der normalen Überprüfung liegt. Speichervolumes und untätige Instanzen, die nach Projektende weiterlaufen, kosten unbegrenzt weiter Geld, unsichtbar, bis jemand zufällig die Rechnung bemerkt. Und wenn ein Regulator, Prüfer oder ein Sicherheitsfragebogen eines Kunden fragt, welche Infrastruktur ihre Daten verarbeitet und wer darauf zugreifen kann, ist „wir sind uns nicht ganz sicher" keine Antwort, die standhält - der Nachweis der Kontrolle über einen Bestand beginnt mit dem Nachweis, dass man weiß, was darin ist. Aus demselben Grund ist auch die Vorfallsreaktion schneller: Man kann nicht eindämmen, was man nicht findet.
Wie Sencai hilft
Sencai verbindet sich mit bestehenden Konten über alle elf unterstützten Provider hinweg - nichts migriert, und Zugangsdaten bleiben im Ruhezustand verschlüsselt und beim Provider jederzeit widerrufbar. Sobald ein Konto verbunden ist, entdeckt Sencai, was bereits vorhanden ist: Instanzen, Netzwerke, Speicher und DNS, über jeden verbundenen Provider hinweg. Bare-Metal- und On-Premise-Server erhalten dieselbe Behandlung über einen leichtgewichtigen Fleet-Agent statt über eine Provider-API. Jede entdeckte Ressource ist Opt-in - nichts gerät unter aktive Verwaltung, bis Sie es wählen, Ressource für Ressource - und jede danach vorgenommene Aktion landet in einem nur anfügbaren, manipulationssicheren Audit-Log. Ein kostenloser Plan deckt fünf verwaltete Ressourcen ab, keine Kreditkarte erforderlich.
Inventar und Provisioning erkunden →