Oracle Cloud Infrastructure (OCI) – Tenancy Access Control mit Network Sources

Zugriffskontrolle auf ein „Virtual Cloud Network (VCN)"

Wenn Sie sich für Oracle Cloud Infrastructure entscheiden, erstellt Oracle eine Tenancy für Ihr Unternehmen. Dabei handelt es sich um eine sichere und isolierte Partition innerhalb der Oracle Cloud Infrastructure, in der Sie Ihre Cloud-Ressourcen erstellen, organisieren und verwalten können.

In dem untenstehenden Diagramm wird eine vereinfachte Cloud-Architektur dargestellt. Im Mittelpunkt steht das VCN, ein virtuelles, privates Netzwerk, das Sie im Oracle-Rechenzentren einrichten. Es ähnelt stark einem herkömmlichen Netzwerk, mit Firewall-Regeln und bestimmten Arten von Kommunikations-Gateways, die Sie verwenden können. Ein VCN befindet sich in einer dedizierten Oracle-Cloud-Infrastructure-Region und deckt einen oder mehrere Classless Inter-Domain Routing (CIDR)-Blöcke ab.

Ein virtuelles Cloud-Netzwerk eines Kunden kann aus unterschiedlichen Komponenten bestehen:
• Netze & Subnetze
• Gateways
• Rechnerknoten (Nodes)
• Datenbanksystem (DBs)

Routentabellen (TRs), Sicherheitslisten (SLs) und Netzwerksicherheitsgruppen bestimmen und definieren die Konnektivität dieser Komponenten und sind damit auch essenziell für die Sicherheit im Gesamtsystem.

Die Tenancy-Verwaltung in der OCI-Konsole ist durch das Identity and Access Management (IAM) gesichert, welches festlegt, wer welche Ressourcen verwalten darf.

Zugriffskontrolle auf die OCI-Konsole

Es scheint, dass damit alle Sicherheitsbedenken ausgeräumt werden können. Tatsächlich gibt es aber noch weitere Sicherheitslücken, die ausgenutzt werden können, um mit einer legalen Benutzerkennung und Passwort Zugriff auf die Tenancy zu erhalten.
Die Sign-In-Seite der OCI-Konsole auf https://www.oracle.com/cloud/sign-in.html ist generell erreichbar. Eine Einschränkung des Zugriffs nur von speziellen IP-Adressen (z.B. sogenannte „Sprungserver" / „Jump Hosts") ist nicht möglich. Die OCI-Konsole ist der virtuelle Eingang zu unserer IT-Infrastruktur beim Cloud-Anbieter. Jeder mit einer gültigen User-ID und einem Passwort kann von überall auf der Welt auf unsere IT-Infrastruktur theoretisch zugreifen.

Wir sprechen hier nicht nur von Bedrohungen durch Hacker oder sonstige Außenstehende, sondern von Bedrohungen durch aktuelle oder ehemalige externe oder interne Mitarbeiter:innen, die aufgrund ihrer Tätigkeiten (noch) im Besitz von Account-Daten sind. Die Zerstörung von virtuellen Infrastrukturen und Systemen ist in der Regel deutlich einfacher als die Zerstörung von physikalischen Strukturen „On Premises". Zudem sind Cloud-Lösungen zusätzlich für den automatisierten Aufbau (Stichwort Ansible, Terraform und Co.) optimiert. Genau diese Mechanismen können von fehlgeleiteten Mitarbeiter:innen bei der Zerstörung „effizient" genutzt werden.
Da in aller Regel sowohl die primäre als auch sekundäre IT-Infrastruktur über dieselbe Tenancy verwaltet werden, ist der potenzielle Schaden ggfs. sogar noch größer als im eigenen Rechenzentrum mit räumlicher Trennung.

Network Sources

„Network Sources" können ein Mittel sein, um diesem Risiko zu begegnen. Eine Network Source ist ein Satz von definierten IP-Adressen. Diese IP-Adressen können öffentliche oder IP-Adressen von VCNs innerhalb der Tenancy sein. Nachdem Sie die Network Source erstellt, haben, können Sie sie in der Policy oder in den Authentifizierungseinstellungen Ihrer Tenancy referenzieren. So sind Zugriffe auf Ihren Ressourcen nur noch von bestimmten IP-Adressen zulässig.

Es gibt zwei Möglichkeiten, mit unterschiedlichem Administrationsaufwand, wie Network Sources zur Absicherung der Tenancy und damit zur Sicherung der IT-Infrastruktur beitragen können:

1. Geben Sie die Network Source in den Authentifizierungseinstellungen Ihrer Tenancy an, um die Anmeldung an der Konsole zu beschränken. Mit dieser Methode wird die Anzahl der virtuellen Zugänge effektiv auf so wenige IP-Adressen wie nötig reduziert. Jeder, der sich von den erlaubten IP-Adressen aus Zugang verschafft, kann jedoch immer noch auf alle Ressourcen zugreifen und sie möglicherweise löschen.

2. Die zweite Methode ist deutlich feiner abgestuft. Über eine IAM-Policy wird definiert, wer Zugriff auf eine Ressource erhält. Somit kann gewährleistet werden, das bestimmte Aktionen nur von zuvor definierten Systemen initiiert werden können.

Beispiel für eine IAM-Policy:
allow group SysAdminUsers to use object-family in tenancy where request.networkSource.name='sysadm'

Beide Methoden können auch in Kombination implementiert werden, um einen gesicherten Zugriff auf die IT-Infrastruktur und eine gesicherte Ressourcenverwaltung zu implementieren, wodurch die oben erwähnten Risiken stark reduziert werden können.