X

Willkommen bei Themen rund um Oracle Technologien, die on-premises oder in der Oracle Public Cloud Verwendung finden.

Recent Posts

CloudDev

IDCS - weitere Instanz zur Trennung des Usermanagements

Der Oracle Identity Cloud Service (IDCS) ermöglicht die Anlage weiterer Instanzen. Dies kann sinnvoll sein, wenn die einzelnen Typen von Benutzern/Logins von anderen getrennt werden sollen. Beispielsweise Kunden von Mitarbeitern oder Administratoren von Mitarbeitern oder Testuserbestände von Produktionsuserbeständen etc. Diese weiteren Instanzen heissen "secondary" oder je nach Dokumentation "stripes". Stripes wird im Weiteren verwendet. Es können mehrere Stripes angelegt werden. Diese besitzen alle dieselbe Funktionalität, d.h. Usermgmt, Anmeldung, SSO, Federations, OAuth/OpenID, Anwendungsintegration, MFA usw. Eine Anlage benötigt den Tenant-Admin bzw. dessen Rechte - typischerweise derjenige der den Tenant angelegt hat. Die Verwaltung erfolgt über die "Service User Console" (beginnend mit "myservices-cacct-...."), die nach dem Login über das Menü am Avator rechts oben erreichbar ist. Ist der Eintrag zur Anlage oder der Button nicht sichtbar liegt das an fehlenden Berechtigungen. Aufruf der Service User Console:   Die Anlage der IDCS Stripes ist hier beschrieben: https://docs.oracle.com/en/cloud/paas/identity-cloud/uaids/multiple-instances.html Damit ist der neue Stripe aktiv und konfigurierbar. Sollen PaaS Instanzen, z.B. Oracle Analytics Cloud (OAC), diesen Stripe nutzen muss der Stripe mit einer Federation zu OCI eingerichtet werden. Hintergrund ist dass über die IDCS Anmeldung des Administrators der IDCS Stripe festgelegt wird in wlechen sich der PaaS Service einklinkt. Ein "Move" von einem Stripe zum anderen ist nicht möglich. Für SaaS Services ist die Konfiguration unabh. der Anlage des SaaS Services. Damit wird im Falle von OAC folgende Konfiguration erzielt:   Eine ausführliche Anleitung wie OAC in einem IDCS Stripe angelegt werden kann findet sich in englisch hier: https://blogs.oracle.com/analytics/post/how-to-create-oac-instances-on-oci-native-using-multiple-stripes-or-instances-of-idcs

Der Oracle Identity Cloud Service (IDCS) ermöglicht die Anlage weiterer Instanzen. Dies kann sinnvoll sein, wenn die einzelnen Typen von Benutzern/Logins von anderen getrennt werden...

Einstieg

Oracle OCI: Security Benchmarking

Mit Oracle OCI erfolgt der Start mit einem "deny-all" Ansatz, d.h. es gibt nur denjenigen der den Tenant angelegt hat, der der Administrator ist. Dieser Account definiert nun die weiteren Berechtigungen über Policies und Groups damit weitere Benutzer über das UI oder eine API Resourcen erstellen, konfigurieren und nutzen können. Ein Großteil der bisherigen Breaches hatte die Ursache in (unabsichtlich) fehlerhaften Konfigurationen, vernachlässigtem Security-Patching, unangepassten Berechtigungen oder gekaperten Accounts. Gartner geht davon aus dass u.a. diese Quellen auch in Zukunft mit Abstand die häufgsten Ursachen für Probleme mit bzw. in der Cloud sein werden. Um die Umgebungen, sei es Cloud oder On-Premises hinsichtlich security-relevanter Einstellungen und Nutzung zu monitoren gibt es eine Vielzahl an Werkzeugen die sich im Bereich IT-Compliance, Konfigurationmanagement, SIEM usw. tummeln. Bestreben einer Umgebung sollte sein, dass diese passende Werkzeuge selbst mitbringt um schon für sich eine entsprechende Sicherheit wahren zu können. Oracle OCI unterstützt diese Ansätze: mit einen definierten sicheren Startpunkt und einem Audittrail über alle durchgeführten Aktionen  mit einem durchgängigen Berechtigungsmodell bzw. dessen Enforcement durch die Verwendung von grundgehärteten Konfigurationen von Oracle oder CIS mit servicespezifischem automatisiertem oder semi-automatisiertem Security-Patching mit einem Monitoring hinsichtlich Aktivitäten und Konfigurationen der Cloudresourcen durch den enthaltenen OCI Cloud Guard mit einem Monitoring hinsichtlich Aktivitäten und Konfigurationen der Oracle Datenbanken die On-Premises oder in einer Cloud sein können durch den enthaltenen OCI Data Safe durch Analyse der Logfiles mit dem vorhandenen OCI Log Analystics durch Weiterleitung der entsprechenden Loginformationen an z.B. SIEM Systeme Die Regelwerke werden dabei automatisch von Oracle angepasst und können teilweise durch den Kunden ergänzt oder geändert werden. Bei einigen der Werkzeuge kommt UEBA zum Ansatz um Abweichungen vom Standard erkennen zu können ohne dass vorher Regelwerke definiert werden. Die Services Cloud Guard und Data Safe sind für OCI Services Stand 3/2021 kostenfrei. Loginformationen und Logweiterleitungen sind bis zu einer bestimmten Grössenordnung kostenfrei, danach pro GB, siehe Preisliste. Neben den Werkzeugen gibt es u.a. auch von CIS ein Regelwerk bezüglich OCI. Eine scriptbasierte Umsetzung ist vorhanden um einen schnellen Abgleich / Report diesbezüglich erstellen zu können. Für eine Prävention sind die sogenanten OCI Security Zones vorhanden, die schon bei der Konfiguration verhindern daß schwache Einstellungen verwendet werden. Beispielsweise sind keine Public IPs für Services möglich. Konfiguration erfolgt auf Compartment Ebene. Alle Mechanismen können über den Oracle Cloud Markplatz um weitere Tools erweitert werden. Weitere 3rd Party Werkzeuge die nicht im Marktplatz vorhanden sind lassen sich manuell installieren.

Mit Oracle OCI erfolgt der Start mit einem "deny-all" Ansatz, d.h. es gibt nur denjenigen der den Tenant angelegt hat, der der Administrator ist. Dieser Account definiert nun die...

Einstieg

Oracle OCI: Federation und andere SSO Verfahren mit IDCS

Oracle OCI bietet über das Menü Identity, Submenü Federation die Möglichkeit Federations (SAML) einzurichten. Abhängig der eingestellten Service Limits sind das bis zu drei Federatons. Eine Federation, mit dem Oracle Identity Cloud Service ist bereits bei der Anlage des OCI Tenants vorhanden.  Oracle Identity Cloud Service kann auch Federations einrichten, daher wird im Wording OCI-native für OCI basierte Federation verwendet im Gegensatz zu IDCS Federation. Beide Benutzermanagementsysteme können parallel genutzt werden. OCI native unterstützt zwei Typen von Federation, einmal mit "Anlage" der Benutzer  und einmal transient wie bei Azure. D.h. im Falle von Azure wird kein User in OCI angelegt und kann damit auch nicht "verwaltet" werden, d.h. keine API Keys usw. gemanagt werden. Das OCI CLI ist trotzdem nutzbar, hier kommen die sogenannten Session Keys zum Einsatz. Berechtigungen werden in beiden Fällen dabei über Gruppenmappings im Rahmen der Konfiguration der Federations zugewiesen. Im Falle von IDCS sind die Gruppen in IDCS dem IDCS Benutzer zuweisbar. Dito in Azure für Azure Benutzer. Um Berechtigungen in OCI zu bekommen müssen natürlich die OCI Gruppen vorhanden sein. Bei der Anlage des Tenants ist genau eine Administrators Gruppe vorhanden. Weitere Gruppen können angelegt werden - schon auch um ein Rollenmodell anzulegen und auch das "least-privilegue" durchzusetzen. Beispiele gibt es hierzu in der Dokumentation im Bereich Best Practices bzw. in der Architecture Corner. Der Unterschied in der Verwendung von OCI-native und IDCS liegt, neben anderen Funktionalitäten, in den unterstützen Integrationen für das SSO. OCI-native IDCS (OCI via IDCS) SAML (max 3 zzgl Gruppenbeschränkungen) SCIM nur für Okta und IDCS SAML SAML JIT OpenIDConnect OAuth, Social Logins Form Fill OCI PaaS Services Integration eigener Anwendungen und Apps Integration OnPremises Anwendungen Radius Client SCIM (push/pull) und weitere Provisioning Möglichkeiten Es liegt nahe trotz aller SSO Möglichkeiten mindestens einen OCI Local User als Notfalluser zu verwenden.Der automatisch vorhandene IDCS ermöglicht die sofortige parallele Nutzung, es ist also keine Entscheidung zu Beginn erforderlich. Anbindungen, z.B. Azure können in beiden Systemen parallel konfiguriert werden. Weitere Blog Artikel zu dem Thema: OCI-native Fedeartion und Azure Stripes: Mehrere unabhängige Benutzerverwaltungen in einem Tenant (englisch) Social Logins wie google, facebook usw. (englisch) weitere IDCS Funktionen über OCI-native hinaus

Oracle OCI bietet über das Menü Identity, Submenü Federation die Möglichkeit Federations (SAML) einzurichten. Abhängig der eingestellten Service Limits sind das bis zu drei Federatons....

Einstieg

Oracle OCI native Federation mit Azure und Limitierung der Azure Gruppen

Oracle OCI bietet über das Menü Identity, Submenü Federation die Möglichkeit Federations (SAML) einzurichten. Abhängig der eingestellten Service Limits sind das bis zu drei Federatons. Eine Federation, mit dem Oracle Identity Cloud Service ist bereits bei der Anlage des OCI Tenants vorhanden.  Oracle Identity Cloud Service kann auch Federations einrichten, daher wird im Wording OCI-native für OCI basierte Federation verwendet im Gegensatz zu IDCS Federation. Beide Benutzermanagementsysteme können parallel genutzt werden. Berechtigungen sind dabei über die Definition der lokalen Gruppen in OCI bzw. Gruppenmappings über Federations zugewiesen. OCI native unterstützt zwei Typen von Federation, einmal mit "Anlage" der Benutzer  und einmal transient wie bei Azure. D.h. im Falle von Azure wird kein User in OCI angelegt und kann damit auch nicht "verwaltet" werden, d.h. keine API Keys usw. gemanagt werden. Das OCI CLI ist trotzdem nutzbar, hier kommen die sogenannten Session Keys zum Einsatz. Bei Benutzern über transiente Federation können dessen Aktivitäten über das OCI Audit Log nachverfolgt werden. Hierzu wird der Identifier verwendet, der vom Federation IDP übergeben wird (z.B. principal). Konfiguration erfolgt auf IDP Seite. Das OCI Auditlog ist 90 verfügbar. Die Konfiguration lässt sich auf 365 Tage erweitern. Ein Export in ein Bucket oder einen anderen, ggf. externen, Service ist möglich. Der häufigste Fall ist die Anbindung an ein SIEM. OCI native mit Azure hat ein paar Limitationen hinsichtlich OCI und hinsichtlich des SAML Standards. Da bei dieser Federation in der Standardkonfiguration immer alle Gruppenmitgliedschaften von Azure des Benutzers übergeben werden kann dies den Rahmen sprengen und dann zu unerwünschtem Verhalten führen. Beispielweise sind Berechtigungen nicht oder nur sporaisch vorhanden. Dieser Effekt trifft bei ca 100 Gruppen auf. Eine weitere Limitation ist der http Header, teilweise unterschiedlich je OCI Service, d.h. Probleme kann es schon unter 100 Gruppen geben. Gruppennamen werden als die Azure ID übergeben und entsprechend im Mapping der Federation eingetragen. Soweit ist alles vollständig beschrieben und unterhalb der Megenbegrenzung  funktionert alles. Um das Gruppenproblem zu lösen gibt es die Möglichkeit Azure-seitig die in der SAML Response übergebene Gruppen zu filtern. Dazu wird die Standard SAML konfiguration verwendet, bei Azure ist OCI als Enterprise Application Template vorhanden. Es sind nun dort Gruppen im Bereich  "User & Groups" der Enterprise Application zuzuordnen, sogenannte Assginments. Effekt ist auch dass später nur User die dort aufgeführt sind ein erfolgreiches SSO durchführen können. In der SAML Konfigruation wird nun ledglich im Bereich  "Single Sign On" und dort bei "User & Claims" für Gruppen der Selektor "Groups assigned to Application" gesetzt. Im Default steht der Selektor aus "All Groups" oder "All Security Groups". Der Rest der Konfiguration erfolgt wie im Standard laut Doku. Screenshots zur Azure Konfiguration:  

Oracle OCI bietet über das Menü Identity, Submenü Federation die Möglichkeit Federations (SAML) einzurichten. Abhängig der eingestellten Service Limits sind das bis zu drei Federatons....

CloudDev

Ressourcen-Kontrolle in der Oracle Cloud Infrastructure

Ressourcen-Kontrolle in der OCI ist die Grundlage für die Kosten-Kontrolle innerhalb des Cloud-Tenants. Dazu stehen eine Reihe von Funktionalitäten zur Verfügung. In diesem Blog-Eintrag möchte ich zwei grundlegende und einfach zu verwendende Möglichkeiten darstellen. Das Setup dauert nur wenige Minuten und ist als Administrator ohne zusätzliche Policies möglich. Die erste Möglichkeit ist eine Kosten-Grenzwert-Benachrichtigung zu erstellen. In der OCI nennt sich dieser Punkt "Budgets" und wird im Artikel detailliert beschrieben. Budget ermöglichen die Benachrichtigung per Email, wenn ein bestimmter Wert tatsächlich überschritten wird oder wenn der Forcast darauf hinweist, dass der Grenzwert überschritten wird.  Die zweite Möglichkeit ist eine Benachrichtigung per Email bei Erstellung bestimmter Ressourcen in der OCI. Wird zum Beispiel eine Datenbank oder eine Compute-Instanz angelegt, bekommt der Administrator eine Email mit einer Reihe von Metadaten, zum Beispiel: Welcher Benutzer hat die Resource angelegt, um was für eine Ressource handelt es sich und wie groß ist diese... Beide Möglichkeiten bieten eine erste, schnelle und transparente Möglichkeit den Kosten-und Ressoucen-Verbrauch der OCI zu überwachen. Es gibt eine Reihe weiterer viel detailliertere Möglichkeiten, auf die ich im Link-Bereich des Artikels hinweise. 1. Kostenkontrolle / Budgets Um zu diesem Punkt zu kommen, navigieren Sie im linken Seiten-Menü auf "Account Management > Budgets" und Erstellen mit dem Button "Create Budget" einen neuen Eintrag. Sie können die Kosten des gesamten Compartments (durch Auswahl des Root-Compartments), eines einzelnen (Sub-)Compartments oder der Cost Tracking Tags überwachen. Cost Tracking Tags können jeder Ressource zugewiesen werden und ermöglichen eine Kosten-Kontrolle mehrer Organisationen innerhalb eines Tenants. In unserem Fall verwenden wir die schnelle Variante und wählen das Root-Compartment aus, durch diese Auswahl werden auch alle Sub-Compartments in die Überwachung eingeschlossen.  Im nächsten Punkt geben wir die Summe ein, die wir als Grenzwert setzen wollen. Die Summe bezieht sich immer auf die Währung, die bei der Abrechnung Ihres Accounts verwendet wird und kann nur als ganze Zahl angegeben werden.  Der nächste Teil ist optional, ich empfehle jedoch umbedingt die "Budget Alert Rule" zu definieren. Diese Regeln können auch zu einem späteren Zeitpunkt definiert und erweitert werden. In unserem Fall verwenden wir die Regel "Forecast Spend", dies bedeutet das die OCI eine Benachrichtigung schickt, wenn das gesetzte Limit in Zukunft zu dem gesetzten Zeitpunkt überschritten wird. Der Forecast-Algorithmus benötigt mindestens 3 Tage Consumption und folgt einer Linearen Extrapolation. Man kann jedoch auch "Actual Spend" setzen, dann wird der tatsächliche Verbrauch als Grenzwert verwendet. Als nächstes wird der Grenzwert-Typ gesetzt hier hat man die Möglichkeit zwischen einer prozentualen und einer absoluten Größe zu wählen. In meinem Beispiel setzte ich das monatliche Budget auf 100€ und den Grenzwert auf 80% mit "Forecast Spend". Das bedeutet im Klartext: Wenn es sich anbahnt, das ich 80€ zum Ende des Monats überschreite, bekomme ich eine Email-Benachrichtigung. Wichtig: Die Regeln setzen immer den Anfang des Bereichnungs-Zeitraumes als Startzeit an, d.h. in der Regel den 1. eines Monats. Bild 1: Eingabe der Parameter (oberer Teil) In den weiteren Feldern kann ich noch die Email-Adresse(n) der Benachrichtigung und den gewünschten Benachrichtigungs-Text verfassen. Nach Bestätigung der Eingaben, ist die Budget-Überwachung aktiv. Persönlich verwende ich diese Überwachung seit März 2019 und es hat bis heute tadellos funktioniert! Bild 2: Eingabe der Parameter (unterer Teil) Ressourcen-Kontrolle Das Aufsetzten der Ressourcen-Kontrolle umfasst ein paar Arbeitsschritte mehr, die aber auch in anderen Bereichen eine Vergrösserung des Administrations-Komfort mit sich bringt. Grundsätzlich geht das Aufsetzten in drei Schritten Erstellen von "Tag Defaults" zum Auslesen der Informationen: Wer und Wann hat diese Ressource erzeugt Erstellen eines "Notification Topics" zur Definition des Benachrichtigungs-Kanals Erstellen von "Events" die eine Benachrichtigung auslösen Tag Defaults Diese Tags werden auf Compartment-Ebene angelegt und jeder Ressource mitgegeben, die innerhalb dieses Compartments angelegt wird. Wird es auf Root-Compartment-Ebene definiert, bekommen alle Ressourcen in allen Compartments diese Tag Defaults. Um Tag Defaults anlegen zu können muss zuerst ein Tag-Namespace mit den dazugehörigen Key-Definitions angelegt werden. Dazu geht man auf Gouvernance > Tag Namespaces und erstellt einen neuen Namespace. In unserem Fall habe ich den Namespace "Operation" genannt. Nach der Erstellung des Namespaces können innerhalb des Namespaces Key-Definitions oder Schlüssel-Namen angelegt werden. In unserem Fall verwende ich die Standard-Namen "CreatedBy" für die automatische Zuordnung des eingeloggten Benutzers und "CreationDate" für den automatischen Zeitstempel der Ressourcen-Erstellung. Ich gebe nur den Namen in den Details an und belasse die Einstellung von Cost-Tracking auf NO und verwende den "Tag Value Type" "Static Value". Anschließend kann ich auf Compartment Ebene den Tag-Default setzen. Dazu navigiere ich zu Identity > Compartments und wähle das Root-Compartment aus. In der Detail-Ansicht gehe ich links auf "Tag Defaults". Mit der Auswahl von "Create Tag Default" wähle ich den Namespace "Operation" aus und den Tag-Key "CreatedBy". In der Default Value setze ich den regulären Ausdruck ${iam.principal.name}. Dieser Ausdruck wird mit dem Benutzer ersetzt, der zum Zeitpunkt der Ressourcen-Erstellung eingeloggt ist. Dies gilt natürlich auch für Erstellungen über die OCI APIs! Der nächste Tag-Default wird mit dem Tag-Key "CreationDate" und dem regulären Ausdruck ${oci.datetime} gefüllt. Wie schon vermuten lässt,wird der Ausdruck durch das aktuelle Zeitstempel/Datum der jeweiligen Region ersetzt. In der Übersichtsseite sieht dann das fertige Konstrukt folgendermaßen aus:  Bild 3: Erstellen von Tag Defaults Jedes Mal, wenn ein Benutzer nun eine Ressource anlegt, können Sie zurückverfolgen, wer und wann diese Ressource angelegt hat. Ein Hinweis am Rande: Falls User die Administrationsrechte Tag besitzen, können diese natürlich die Tags im Nachhinein abändern. Für fälschungssichere Verfolgung muß man zusätzlich die Audit- Logs überprüfen (Link am Ende des Textes). Erstellen eines "Notification Topics" Für die eigentliche Benachrichtigung muss zuerst festgelegt werden, wie und an wem die Benachrichtigung erfolgen soll. Dies erreicht man durch eine Notification Topic. Navigieren Sie dazu auf Application Integration > Notifications > Create Topic und erstellen ein Topic. Ich habe es in unserem Fall "CreationAlert" genannt. Im zweiten Schritt geht man auf die Detail-Ansicht des Topic und erstellt eine Subscription. Der Einfachheit halber verwenden wir hier Email. Es gibt noch eine Reihe andere Möglichkeiten wie Pager, Slack, Functions etc. Nach Eingabe der Emailadresse ist dieser Punkt abgeschlossen. Bild 4: Erstellen von Notification Topics Erstellen von "Events" Der letzte Schritt ist das Setzen von Events. D.h. nahezu jede Aktion, die in der OCI mit Ressourcen durchgeführt wird, kann als Trigger für eine Notification verwendet werden. Um dies zu bewerkstelligen, navigieren Sie auf Application Integration > Event Service > Create Rule. In dieser Regel können Sie mithilfe von Drop-Down-Menüs nach belieben Events aussuchen, bei denen Sie benachrichtigt werden wollen. In unserem Beispiel soll bei folgenden Events benachrichtigt werden: Erstellung einer Compute Instanz Anlegen eines neuen Benutzers im Cloud Account Erstellen einer (Autonomen) Datenbank Erstellen eines Analytics Services Sie können sich hier frei entfalten. Sie müssen nur die Condition "Event Type" und den gewünschten Service Namen auswählen und können dann den Status (Create, Update, Delete, etc.) setzen, bei dessen Erreichung Sie eine Nachricht bekommen möchten. Im letzten Punkt wählen Sie noch die Aktion, die aus dem Event generiert werden soll. In unserem Fall wählen wir "Notification" im Root-Compartment und wählen die eben erstellte Benachrichtigung "CreationAlert" aus. Bild 5: Erstellen von Rssourcen-Events Wenn Sie die beschriebenen Schritte durchgeführt haben, sind Sie fertig.Jedes Mal wenn einer dieser Events erfolgt, bekommen Sie eine Email im JSON-Format, in der wichtige Meta-Informationen hinterlegt sind. Für mich persönlich sind dabei die wichtigsten Informationen: Wer hat welche Ressource angelegt und wie groß ist diese! Bild 6: Benachrichtigungs-Email mit Ressourcen-Typ, Name, Erstellungs-Datum und Benutzer der die Ressource erstellt hat (Reale Werte sind ausgeschnitten!) Fazit Budget, Tag-Defaults, Notification und Events gehören zu den wichtigen Werkzeugen, um die Abläufe im OCI-Account transparenter zu machen. In meinem Beispiel verwalte ich einen Tenant mit 100+ Benutzer und habe immer einen Überblick über Ressourcen-Ausreißer und mein zugeordnetes Budget. Das Ganze ist in wenigen Minuten aufgesetzt. Der Aufwand lohnt sich auf jeden Fall! Links: Dokumentation der beschriebenen Abläufe: Einrichten von Budgets Aufsetzen von Namespaces  Erstellen von Tag Defaults  Erstellen von Notifications  Erstellen von Events  Audit Logs Weiter Tools und Links zur Kostenkontrolle: Beschreibung der neuen Kosten Analyse in der OCI (englisch) Externes Kostenüberwachungs-Tool mit weitreichenden, detaillierten Analyse-Möglichkeiten (englisch)  

Ressourcen-Kontrolle in der OCI ist die Grundlage für die Kosten-Kontrolle innerhalb des Cloud-Tenants. Dazu stehen eine Reihe von Funktionalitäten zur Verfügung. In diesem Blog-Eintrag möchte ich...

Sicherheit

Oracle Cloud Infrastructure Audit Search für Einsteiger

Die Oracle Cloud Infrastructure (OCI) bietet die Möglichkeit, alle durchgeführten administrativen Operationen nachzuvollziehen und zu durchsuchen. Die Steuerung der OCI beruht im Kern auf der Nutzung einer REST-API. Unabhängig von dem verwendeten Eingabemedium Desktop, API oder SDK alle Befehle werden immer über die REST-API an die OCI weitergegeben. Diese Funktion macht sich der Oracle Cloud Infrastructure Audit Service zu nutze. Alle API-Calls innerhalb eines Tenants werden zentral gespeichert und können durchsucht und exportiert werden. Alle Audit Logs werden im Default 90 Tage vorgehalten, können jedoch bis maximal 365 Tage gespeichert werden. Diese Speicherzeit kann an folgenden Ort geändert werden: Oben rechts auf das Benutzer-Profil () gehen und die Tenancy: xxx auswählen. Es werden auf der Seite Detail-Informationen der Tenancy angezeigt. Von hier aus klicken Sie "Edit Audit Retention Policy", geben Sie den neuen Wert ein und klicken "Submit". Die Änderung der Anzeige kann einige Zeit benötigen! Die neue Speicherzeit bezieht sich immer auf die aktuelle Region und allen enthaltenen Compartments. Das Suchen kann man über die Audit Suchseite durchführen, um dorthin zu gelangen klicken Sie im linken Hamburger Menü auf Governance > Audit. Sie können auch die Audit-Daten exportieren. Dies wird momentan noch durch einen MyOracleSupport Service Request gestartet und im Object Storage des Tenants gespeichert. Der Link auf die Vorgehensweise ist in den weiterführenden Links aufgeführt. Ein Hinweis: Ich stelle in diesem Blog die Audit-Suche vor und nicht das Audit Logging der OCI. Die Audit-Suche bezieht sich auf die gesamte OCI API und das Audit Logging bezieht sich auf Events/Streams. Die Audit-Suchfunktionen im Detail Das Suchfenster bietet eine Reihe von Eingabeoptionen und eine Ausgabeliste. Im Folgenden wird erklärt wie man die Einstellungen der Komponenten am Besten einsetzt. Bild 1: Ein- und Ausgabe-Fenster der Audit-Suche Eingabefeld 1 - Compartment: Wenn nach einem Audit-Eintrag gesucht wird, muss immer das spezifische Compartment angegeben werden, in dem der Eintrag vorhanden ist. Die Suche erfolgt nicht in Abhängigkeit von Compartment-Bäumen es wird immer nur das eine Compartment durchsucht, das angegeben wird! In der Praxis bedeutet es, das man wissen muss in welchem Compartment der gesuchte Eintrag vorhanden ist. Eingabefeld 2 - Start Date: Um die Suche möglichst kurz zu halten, hilft es den Suchzeitraum möglichst genau einzugrenzen. In der Praxis hat es sich bewährt die Minimalgröße auf 24 Stunden zu begrenzen. Daher ist es am besten das Anfangs-Datum immer um 00:00 starten zu lassen. Es wird hier keine relationale Datenbank durchsucht, sondern Flat-Files im Object-Storage, dies benötigt Zeit! Eingabefeld 3 - End Date: Wie beim Start Date würde ich hier immer den Zeitstempel 00:00 verwenden und zum Beispiel den nächsten Tag verwenden, um die Suche einzugrenzen. Eingabefeld 4 - Keywords: Hier kann nach bestimmten Ausdrücken gesucht werden. Da das Ergebnis der Audit-Suche JSON Objekte sind, können auf alle enthaltenen Werte gesucht werden. Wichtig hierbei: Wenn man doppelte Anführungsstriche verwendet, wird nach dem exakten Wert gesucht. Ohne Anführungsstriche wird nach einem Teilausdruck eines Wertes gesucht. Um zum Beispiel nach einer Ressource mit dem Namen TestDatenbank zu suchen, verwendet man am besten den Ausdruck "TestDatenbank". Sucht man nach allen JSON Objekten, die zum Beispiel peter.lustig@lustig.de enthalten, würde ich den Ausdruck peter.lustig verwenden (ohne Anführungsstriche). Eingabefeld 5 - Request Action Types: Mit dem Request Types kann man wiederum die Menge der Such-Ergebnisse reduzieren. Je nachdem was man sucht, kann man hier zwischen den REST Aufrufen: GET, POST, PUT, PATCH und DELETE einschränken (man kann diese Typen auch kombinieren). Die Action Types sind äquivalent zu den REST Typen, hier eine sehr kurze Beschreibung:  GET - API liest eine Ressource POST - API legt eine Ressource an PUT - API überschreibt eine Ressource PATCH - API macht eine Änderung der Eigenschaft/Wert einer Ressource DELETE - API löscht eine Ressource Ausgabefeld 6 - Ergebnisse: Dieses Feld ist nur lesend, es wird die Anzahl der durchsuchten JSON Objekte angezeigt. Wichtig: Nach einer gewissen Anzahl von durchsuchten Objekten kommt eine einmalige Unterbrechung und der Hinweis ob weiter gesucht werden soll. Erste gefundene Ergebnisse werden sofort angezeigt, aber die Suche läuft im Hintergrund weiter. Noch ein Hinweis: Die Audit-Suche ist in der Lage ca. 50 JSON Dokumente pro Sekunde zu durchsuchen. Da jede Aktion (Lesen, Schreiben, Ändern, Löschen) der API in ein JSON Dokument gesichert wird, fallen eine Menge von Daten an, die es zu durchsuchen gilt. Daher ist es ratsam die Suche zeitlich so weit wie möglich einzugrenzen! Beispiel 1 - Suche nach dem Benutzer der eine Ressource angelegt hat Ist eine Ressource nicht bezeichnet ist es oft schwierig den Besitzer zu finden. Mit der Audit Suchfunktion hat man sehr schnell rausgefunden, wer die Ressource angelegt hat. Man benötigt von der Ressource folgenden Informationen, die man am besten auf der Detail-Ansicht findet: Compartment Erstellungsdatum Ressourcen Name Hat man die Daten herausgesucht, wählt man auf der Audit-Suchseite das Compartment aus, grenzt das Datum auf 24 Stunden ein (Anfangsdatum 00:00 des Tages / Enddatum 00:00 des Folgetages) und gibt den exakten Ressourcen-Namen in Hochkommas an. Als Filter kann man noch POST bei Request Action Types angeben, da man ja nach dem JSON Dokument der Erstellung der Ressource sucht. Das JSON Ergebnis, kann in der Detail-Ansicht angezeigt werden. Die Einzelnen Dokument Teile sind eingeklappt, um Platz zu sparen. Um den Erzeuger eines Objektes zu finden muss man den Parameter "Data" dann den "Identity" aufklappen und unter dem Parameter "principalId" steht der Erzeuger der Ressource. Bild 2: Ergebnis der Suchen nach dem Erzeuger einer Ressource Beispiel 2 - Suche nach Aktivitäten eines Benutzers Ein weiteres Beispiel ist die Suchen nach den Ressourcen-Erstellungs-Aktivitäten eines einzelnen Benutzers. Für diese Abfrage benötigt man einen Zeitraum, das Compartment, den Benutzernamen und den Request Action Type. Wie schon in dem vorherigen Beispiel, muss man bei der Suche nach Ressourcen-Erstellungs-Aktivitäten den Type POST verwenden. Je länger der Zeitraum, desto länger läuft die Suche. In unserem Fall verwenden wir einen Monat, ein Compartment und den Benutzernamen geben wir ohne Anführungsstriche ein.  Bild 3: Ergebnis der Suche nach allen Benutzeraktivitäten bezüglich Ressourcen-Erzeugung Diese Suche läuft selbstverständlich recht lang (>10 Minuten). An dieser Stelle soll noch einmal verdeutlicht werden, daß es immer wichtig ist, den Suchraum zu begrenzen, sei es durch die Verkleinerung des Suchfensters, durch die Auswahl eines Request Action Types (POST, PUT, GET, PATCH, DELETE) und/oder die Verwendung eine Suchbegriffs.  Fazit Die Audit-Suche ist ein sehr wirksamer Service, wenn es darum geht detaillierte Antworten auf administrative Fragen zu bekommen. Da in der OCI alles über die REST-API agiert, sind die Audit JSON Dokumente die "Single-Source-of-Truth", wenn es darum geht Geschehnisse innerhalb der OCI nachzuvollziehen. Die Möglichkeiten entweder schnell in der Oberfläche zu suchen oder die Dokumente als Bulk-Export weiterzuverarbeiten, ermöglichen ein sicheres und fälschungssicheres Auditing der Aktionen. Weiterführende Links Exportieren von Audit Daten Audit Dokumentation  

Die Oracle Cloud Infrastructure (OCI) bietet die Möglichkeit, alle durchgeführten administrativen Operationen nachzuvollziehen und zu durchsuchen. Die Steuerung der OCI beruht im Kern auf der Nutzung...

CloudDev

JSON nativ auch mit Oracle JDBC 20c

Aktuell als Beta-Version in unserer Cloud zum Test verfügbar bietet Oracle Database 20c neben vieler anderer Features einen neuen JSON-Datentyp an, der den bisherigen Umgang mit JSON-Dokumenten weiter vereinfacht und darüber hinaus Vorteile bei Platzverbrauch und Performance bieten kann. Auch Java-Programmierer profitieren vom neuen JSON-Datentyp, denn der neueste Oracle Database 20c JDBC Treiber ermöglicht eine transparente Einbindung bestehender JSON APIs für Java. Bestehende JSON-Datenobjekte können somit ohne großen Programmier- und auch ohne Konvertierungsaufwand leicht in die Datenbank übernommen werden. Der neue JSON-Datentyp in Oracle Database 20c Es gibt viele Blogs, die bereits über den neuen JSON-Datentyp in Oracle Database 20c berichten. Deswegen will ich hier nur kurz darauf eingehen als Mittel zum Zweck - um zu erklären, was "unter der Haube" und damit im JDBC Treiber geschieht. Ein kurzes SQL-Beispiel für den neuen JSON-Datentyp in Oracle Database 20c könnte wie folgt aussehen: CREATE TABLE EMP (empData JSON); Hier wird eine neue Tabelle angelegt mit nur einer Spalte, die JSON- Dokumente enthält - im echten Leben bitte immer mit einer Primärschlüssel-Spalte. In Datenbank Versionen vor 20c konnten JSON- Dokumente in CLOB,BLOB und STRING Spalten abgelegt werden, ein Check-Constraint sorgte dafür, daß die Spalte inhaltlich als JSON betrachtet wurde und somit JSON-spezifische Operationen darauf ausgeführt werden konnten. Die interne Speicherung der JSON- Dokumente erfolgte vor Version 20c noch als Text bzw. String, also noch nicht optimiert. Und damit stoßen wir auf den ersten großen Unterschied zum neuen JSON-Datentyp mit Oracle 20c: die Datenbank legt JSON-Dokumente nun in einem internen Binär-Format ab, das schneller gelesen und interpretiert werden kann und auch Platz spart, sowohl beim Speichern als auch bei der Übertragung über das Netzwerk. Dieses Binärformat trägt den Namen "OSON", in Anlehnung an die Namen Oracle und JSON. Die JSON-Strukturen werden also nicht bei Ablage in Objekt-Strukturen übersetzt; diese wären wahrscheinlich zu unflexibel gewesen, zu starr in ihrer Struktur. Nach Erzeugung einer Tabelle mit JSON-Datentyp kann auf die Spalte direkt mit SQL samt JSON-Hierarchien zugegriffen werden. Ein JSON- Dokument läßt sich direkt einfügen, z.B.: INSERT INTO EMP VALUES (    JSON       {'name': 'Smith',        'job': 'Programmer'} ); Auch Abfragen auf JSON-Dokumente sind mit Version 20c direkt möglich, ohne Sonderbehandlung der betroffenen Spalten durch "treat as json": SELECT t.data.name.string() FROM EMP t WHERE t.data.job.string() = 'Programmer'; Eine vergleichbare Abfrage in vorhergehenden Versionen wie 18c,19c sähe ein klein wenig komplexer aus: with json_doc as (select treat (empData as json) as jsontreat from emp) select j.jsontreat.name from json_doc j where j.jsontreat.job = 'Programmer'; Das interne OSON-Format Gelangen wir nun zu des "Pudels Kern", zum JDBC Treiber und wie JSON-Datentypen darin behandelt werden. Kurz gesagt und vorweggenommen kann dieser Treiber das interne OSON-Format direkt verwenden bzw. erzeugen, so daß die Datenbank diesen Schritt nicht übernehmen muß und die Daten bereits optimiert durch das Netz übertragen werden. Je größer das JSON-Dokument, desto größer die Ersparnis im OSON-Format. Hier ist eine kleine Größen-Übersichts-Tabelle meiner Kollegen aus dem Product Management zu sehen: Einen spürbaren Performancegewinn erzielt die Oracle Datenbank gegenüber der bloßen Speicherung im Text-Format durch den internen Aufbau von OSON. Attributnamen verschwinden und werden durch Pointer ersetzt, zusätzliche Metadaten über die relative Position der Werte von Attributen ermöglichen schnelleren Zugriff durch Überspringen und direkten Zugriff. Und natürlich fehlen dann auch alle Klammern und Quotes. So wird beispielsweise aus einem JSON-Dokument der Form: {"name":"Smith","job":"Programmer","salary":40000} Eine interne Repräsentation singemäß ähnlich dieser: Metadaten: "name"->0, "salary"->1, "job"->2 Offsets: [0->0 , 1->17, 2->7] Werte: Smith,Programmer,4000 Auf diese Weise werden JSON-Abfragen aber auch -Änderungen spürbar wenn nicht gar drastisch schneller. Hierzu zwei Diagramme meiner Kollegen aus dem Product Management zu Queries und Updates von JSON Dokumenten: Der JDBC Treiber 20c Aus JSON-Tabellenspalten können über den Treiber direkt JSONP und JSONB Objekte gefüttert und gelesen werden, d.h. bereits bestehender Java Code muß nicht erst umständlich nach JSON-Text serialisiert werden. Der Zugriff auf JSON-Spalten erfolgt dabei völlig Norm-Konform und ohne augenscheinlichen proprietären Code. Das Auslesen der JSON-Spalte erfolgt zunächst wie gehabt durch ein SELECT-Statement, eingebettet in eine entsprechende Java Klasse:      ResultSet rs = stmt.executeQuery("SELECT empData FROM EMP"); Dann werden die Datensätze eingelesen und die JSON-Spalte über einen getObject() Aufruf geholt. Ein Parameter des getObject-Aufrufs ist das Zielformat bzw. der Zieltyp, in den das JSON eingelesen werden soll. Und dies ist die Besonderheit am neuen JDBC Treiber - es gibt mehrere mögliche vordefinierte Zieltypen, die das interne Speicherformat optimal überführen und weitere Codierung, Parsing, Konvertierung überflüssig machen.       rs.next();       javax.json.JsonObject smith = rs.getObject(1, javax.json.JsonObject.class); In diesem Beispiel wird direkt ein "javax.json.JsonObject" zurückgegeben, d.h. der Treiber erzeugt aus dem internen Format ein Objekt, das man direkt nach Java Standard JSR-374 (JSON-P) benutzen kann um Attribute auszulesen und zu ändern. String jobName = smith.getString("job"); Neben JsonObject sind einige weitere solcher Datentyp-Mappings im JDBC Treiber hinterlegt. Dieselbe JSON-Spalte kann problemlos in folgende Typen übertragen werden:   Zieltyp Variante Zweck java.lang.String java.io.Reader java.io.InputStream JSON als Text String-Verarbeitung, Eingabe-Stream für diverse JSON Parser oracle.sql.json.OracleJsonValue javax.json.JsonValue JSON als Baum-Modell Verwendung per JSON-P API, Oracle-Eigenes Baum-Modell oracle.sql.json.OracleJsonParser javax.json.stream.JsonParser JSON als Event-Modell / Parser Vorbereitung für JSON-B API, d.h. einfaches Binding von Java Klassen an JSON oracle.sql.json.OracleJsonDatum pures OSON Für eigene Zwecke / Debugging Richtig gesehen, der JDBC Treiber kommt mit einer eigenen API zur Verarbeitung von JSON daher. Damit ließe sich weiter Platz sparen, weitere JSON APIs könnten weggelassen werden, wenn man sich auf OracleJsonValue bzw. OracleJsonObject beschränkte. Eine vollständige Liste aller im Treiber enthaltenen Klassen ist auch für Version 20c bereits online verfügbar und kann hier eingesehen werden: https://docs.oracle.com/en/database/oracle/oracle-database/20/jajdb/index.html Dies gilt auch für die gesamte Dokumentation der Datenbank Version 20c mit allen neuen Features: https://docs.oracle.com/en/database/oracle/oracle-database/20/index.html   JSON-P, JSON-B und Jackson Neben dem bisher angedeuteten Mapping von OSON in ein JsonObject gemäß der JSONP Spezifikation kann das eingelesene Objekt auch direkt an eine reguläre Java Klasse, ein POJO, gebunden werden. Dafür existiert die Java Spezifikation JSR-367, JSON-B oder auch JSON-Binding API. Diese setzt auf JSON-P auf (der API für JSON-Verarbeitung oder auch -processing) und benötigt für die Kopplung an ein beliebiges Java Objekt (POJO) einen JsonParser statt eines JsonObjects. Das sieht sinngemäß wie folgt aus: rs.next(); javax.json.stream.JsonParser parser = rs.getObject(1, javax.json.stream.JsonParser.class); org.eclipse.yasson.YassonJsonb jsonb = (org.eclipse.yasson.YassonJsonb)JsonbBuilder.create(); EmpPojo e = jsonb.fromJson(parser, EmpPojo.class); String jobName = e.getJob(); Hier bedient sich der Programmierer aber eines kleinen Tricks: die JSONB Referenz-Implementierung YASSON kennt das Binding von einem JsonParser an ein POJO. In der Spezifikation selbst ist dieses Mapping leider nicht enthalten. Deswegen wird hier der JsonbBuilder in den YassonJsonb gecastet.   Ältere JSON Projekte verwenden vermutlich die Jackson API, um aus JSON Objekten Java Klassen zu erzeugen bzw. zu befüllen. Jackson bietet ebenfalls JSON Parser und ein JSON Binding, kann aber lediglich Brücken zu JSONP und JSONB schlagen und akzeptiert selbst keine JsonParser oder JsonObjects nach JSR Standard. Trotzdem kann aus einem JSON-Datentyp in Oracle via Jackson ein Java Objekt/POJO entstehen. Allerdings muß dazu das OSON Format tatsächlich nach Text bzw. in einen Stream konvertiert werden. Aber es funktioniert auch in diesem Fall:   rs.next(); java.io.Reader smith = rs.getObject(1, java.io.Reader.class); com.fasterxml.jackson.databind.ObjectMapper objectMapper = new com.fasterxml.jackson.databind.ObjectMapper(); EmpPojo emp = objectMapper.readValue(smith, EmpPojo.class); String jobName = emp.getJob(); Vollständige Beispiele für JDBC 20c mit JSONB, JSONP und Jackson können auf https://github.com/ilfur/oraJDBC_JSON eingesehen und heruntergeladen werden.   Viel Erfolg und Spaß beim Testen und Benchmarking !  

Aktuell als Beta-Version in unserer Cloud zum Test verfügbar bietet Oracle Database 20c neben vieler anderer Features einen neuen JSON-Datentyp an, der den bisherigen Umgang mit JSON-Dokumenten weiter...

CloudDev

Komplexe Java Programme in Oracle ausführen - warum und wie ?

Das „Warum“ ist schnell geklärt: Hauptsächlich dient dies zur Beschleunigung der Interaktion von Java-Programmen mit der Datenbank durch drastische Reduzierung der Latenz-Zeiten. Je häufiger ein Java Programm Aufrufe an die Datenbank absetzt, egal ob lesend oder schreibend, desto stärker profitiert das Programm davon, daß keinerlei Netzwerk-Stack mehr im Wege steht. Man kann im absoluten Idealfall vom Faktor 10-12 sprechen, um den das Programm dann schneller läuft. Nicht-Datenbank-Operationen laufen mit etwa gewohnter Geschwindigkeit ab. Der tatsächliche Performance-Gewinn hängt ab von der Mischung aus Datenbank-Operationen und z.B. Berechnungen und Datei-Zugriffen. Von solch kurzen Latenzen profitieren insbesondere langlaufende Operationen wie Batch- und ETL Jobs, zum Beispiel aus Host-Migrationen oder in Java selbstgeschriebene Laderoutinen. Es gibt eine Fülle von Beispielen dafür, wie einfache Java Programme in die Datenbank geladen und beschleunigt ausgeführt werden. Diese Beispiele nutzen meist nur die JDBC API und verwenden kaum Unterklassen oder zusätzliche Frameworks. Aber lassen sich auch beliebig komplexe Programme in der Datenbank ausführen ? Die Oracle Datenbank kommt mit einer sehr restriktiven Sandbox daher, bei der Java Programmen nahezu alles verboten wird mit Ausnahme des internen Zugriffs auf Datenbank-Objekte via JDBC. Diese Sandbox und damit verbunden das Setzen notwendiger Java Permissions bilden die hauptsächliche Hürde. Zweitens prüft die Datenbank beim Laden von Java Code alle Abhängigkeiten der geladenen Java Klassen – sowohl Compile-Time als auch Runtime-Dependecies werden geprüft. Sind sie nicht erfüllt weil Klassen fehlen oder abhängige Klassen als „INVALID“ gelten, ist auch die frisch geladene Klasse „INVALID“ und läßt sich nicht aufrufen. Zum Glück helfen Werkzeuge wie das online Maven-Repository bei der Suche nach nötigen abhängigen Bibliotheken, und einfache SQL Skripte erleichtern das Auflösen von Abhängigkeiten in der Datenbank nach einem Ladeversuch. Ein gutes, weil gängiges Beispiel für ein komplexeres Java Programm ist eines, das im Umgang mit einer Datenbank typischerweise die Java Persistence API, kurz JPA nutzt. Die JPA Referenz-Implementation des EclipseLink Frameworks bringt ca 10MB komprimierte Java Klassen mit sich, inklusive nahezu aller Abhängigkeiten. Das sind etwa 4500 Java Klassen, die XML Konfigurations-Dateien auslesen, dynamisch Klassen suchen und analysieren (mit Hilfe der Reflections API) und mit anderen komplexen Abhängigkeiten wie Dependecy Injection, Expression Language, Transaktionen, Annotationen und vielem mehr. Genügend komplex und sehr gängig, sollte man meinen, und daher ein idealer Kandidat. In wenigen Schritten ist ein solches Beispiel-Programm geladen, und diese Schritte sind:   1) Laden der JPA Basis Klassen und deren Abhängigkeiten Innerhalb der Oracle Datenbank gibt es keinen CLASSPATH, mit dem nach Java Klassen gesucht wird. Die Java Klassen werden beinahe wie in einem Dateisystem in einer internen BLOB Tabelle abgelegt. Diese wird durch einen sogenannten „Resolver“ durchsucht. Ein Resolver kann so konfiguriert werden, daß er bestimmte Namespaces auch anderer Datenbank-Benutzer in seine Suche aufzunehmen vermag. Die Java Klassen werden entweder mittels SQL Kommando geladen - vorausgesetzt, die Java Klassen liegen auf einem Dateisystem des Datenbank Servers – oder mit dem Datenbank-Utility „loadjava“, das man überall sonst betreiben kann. „loadjava“ ist nicht Teil einer Datenbank Client Installation, es gehört zu den Binärdateien einer Datenbank-Server-Installation. Eine mögliche Syntax, um die JPA Basisklassen zu laden, .jar für .jar, lautet wie folgt: loadjava -oci8 -resolve -user UN/PW@tnsservice datei.jar Alle compiletime- und runtime-dependencies sollten geladen werden, die man auf jeden Fall braucht. Für die (aktuelle) EclipseLink 2.7.7 Version werden folgende .jars benötigt:   cdi-api-2.0.SP1.jar javax.el-api-3.0.0.jar javax.inject-1.jar validation-api-2.0.1.Final.jar javax.interceptor-api-1.2.2.jar javax.json-spi-1.1.4.short.jar javax.persistence-2.1.0.jar javax.resource-api-1.7.1.jar org.eclipse.persistence.jpa.jpql-2.7.7.jar org.eclipse.persistence.jpa-2.7.7.jar org.eclipse.persistence.antlr-2.7.7.jar org.eclipse.persistence.asm-2.7.7.jar org.eclipse.persistence.core-2.7.7.jar Wie kommt man darauf, welche Abhängigkeiten existieren? Trial and error ist sicher eine Möglichkeit um herauszufinden, welche .jars man benötigt. Aber welche Version der .jars sollte man verwenden um unnötige Folgeprobleme zur Laufzeit zu vermeiden? Das offizielle Maven Repository ist hierbei eine großartige Hilfe. Äußerst umständlich waren die Zeiten, als es so etwas noch nicht gab: https://mvnrepository.com/artifact/org.eclipse.persistence/org.eclipse.persistence.jpa/2.7.7 Fehlermeldungen beim Laden der Java Klassen über „loadjava“ sind nicht besonders aussagekräftig. Nach einem Ladeversuch können Fehler jeglicher Art, z.B. über noch fehlende Klassen, über die Datenbak-View „USER_ERRORS“ eingesehen werden:   select * from user_errors where text like 'ORA-29521%';   2) Auflösen aller Abhängigkeiten (bzw. nur der meisten) Nicht alle Abhängigkeiten sind notwendig um ein JPA-basiertes Programm auszuführen. Es wird beim Laden der .jar Dateien definitiv zu Fehlern kommen über nicht auflösbare Klassen. Für ein gängiges JPA-Programm können wir z.B. auf Komponenten wie OSGI und ANT gerne verzichten und lassen somit etwa 10 Abhängigkeiten offen. Die zugehörigen Klassen werden kaum bis nie genutzt und bleiben damit gerne „INVALID“.   In meiner Umgebung sind und bleiben folgende Java Klassen INVALID: org/eclipse/persistence/javax/persistence/osgi/Activator org/eclipse/persistence/javax/persistence/osgi/OSGiProviderResolver$ForwardingProviderUtil org/eclipse/persistence/javax/persistence/osgi/OSGiProviderResolver org/eclipse/persistence/tools/weaving/jpa/StaticWeaveAntTask javax/resource/spi/ActivationSpec javax/resource/spi/ResourceAdapterAssociation javax/resource/spi/BootstrapContext javax/resource/spi/ResourceAdapter Trotzdem sollten so viele Java Klassen wie möglich auflösbar sein und den Status „VALID“ erhalten. Es kommt durchaus vor, daß Klassen beim Laden in falscher Reihenfolge geprüft werden und daher erst einmal INVALID sind. Bitte nicht verzagen, denn die wiederholte Ausführung eines kleinen SQL’s bis die Zahl der INVALID Klassen nicht weiter schrumpft ist hier sehr hilfreich und erforderlich:   select 'alter java class "'||object_name||'" resolve;' from user_objects where object_type= 'JAVA CLASS' and status = 'INVALID'; Diese Abfrage erzeugt ein SQL Skript das namentlich alle INVALID Klassen erneut prüft. Das Ergebnis dieser Abfrage wäre zu kopieren und als Skript gegen die Datenbank laufen zu lassen. Dies erfolgt Runde um Runde, bis die Zahl der INVALID Klassen sich nicht mehr verändert, sie sollte sich in etwa auf die Zahl 15 einpendeln.   3) Laden des eigenen Codes Nachdem die Basis Klassen geladen wurden ist es nun an der Zeit, den selbstgeschriebenen Code (*.class) und dessen Konfiguration (persistence.xml) zu laden. Dies kann wie bereits gehabt geschehen, indem alles in eine .jar Datei verpackt und dann mit loadjava geladen wird. Alternativ, und das wird auch häufig genutzt um schnell Änderungen in der Konfiguration oder im Code zu patchen, können die Dateien auch einzeln geladen werden. Selbst der Java Quellcode könnte geladen und dabei innerhalb der Datenbank übersetzt werden, aber ein vorhergehender Maven Build oder gar eine grafische IDE ist wesentlich eleganter und aussagefähiger beim Compilieren der Klassen. In unserem Beispiel laden wir der Einfachheit halber tatsächlich den Quellcode und lassen ihn in der Datenbank übersetzen. Die Übersetzung erfolgt automatisch beim Laden. Zunächst folgen die Lade-Operationen, danach können Sie den Quellcode einsehen, kopieren und lokal für den Ladevorgang speichern:   loadjava -oci8 -resolve -user UN/PW@tnsservice com/ichag/simplejpa/Workers.java loadjava -oci8 -resolve -user UN/PW@tnsservice com/ichag/simplejpa/StartMe.java loadjava -oci8 -resolve -user UN/PW@tnsservice META-INF/persistence.xml Ganz besonders wichtig ist hier, daß das loadjava-Tool den korrekten Pfad zu Konfigurations-Dateien und Java Klassen auf den Weg bekommt. Denn diese Pfadangabe werden genau so auch in die Datenbank übernommen. Der Quellcode der Entity Klasse „Workers“ wäre abzuspeichern im Verzeichnis „com\ichag\simplejpa“ , damit loadjava den Pfad auch korrekt verwendet:   Die „Main“ Klasse, d.h. die steuernde Klasse, die Daten abfrägt und auch neue Daten erzeugen könnte, sollte ebenfalls im Verzeichnis „com\ichag\simplejpa“ abgelegt werden: Nun folgt die Konfigurationsdatei, die festlegt welche Java Klassen welcher Datenbank-Connection zuzuordnen sind – und wie die Datenbank zu erreichen ist. Das Besondere: innerhalb der Oracle Datenbank ausgeführte Java Programme benötigen keinen herkömmlichen Connect String mit Angabe von Host, Port und Servicenamen. Die vom Treiber bzw. von der Datenbank bereitgestellte „DefaultConnection“ reicht aus. Auch die Datei „persistence.xml“ muß in einem Unterverzeichnis abgelegt sein, dieses muß auf den Namen „META-INF“ lauten. Mit Großbuchstaben.   Um eventuellen Ärger mit copy&paste zu vermeiden sind die drei Dateien auch auf Github verfügbar: https://github.com/ilfur/SimpleJPAinOJVM Damit der Code auch richtig läuft muß eine Tabelle „Workers“ im gleichen Datenbank-Schema existieren wie der Code – so ist das Beispiel nunmal geschrieben. Das SQL Skript für die Tabelle “Workers”: 4) Erstellen einer Stored Procedure, die das Java Programm aufruft bzw. startet Per SQL kann nun eine Stored Procedure erzeugt werden, die versucht alle Parameter mit ihren Datentypen von SQL nach Java zu übermitteln und eine sogenannte „static“ Methode im Java Code aufruft. Die standardmäßige „main” Methode ist eine solche und wird hier im Beispiel auch verwendet:   create or replace procedure GetWorkersJPA (dummy IN varchar2) as language java name 'com.ichag.simplejpa.StartMe.main(java.lang.String[])'; 5) Java Permissions setzen So ziemlich alles, was nicht direkt mit der Datenbank zu tun hat, ist erst einmal für Java innerhalb der Datenbank verboten, z.B. Dateizugriffe, Netzwerkzugriffe und vieles mehr. Stößt man bei Ausführung von Java Code auf ein Verbot, wird dies von der Datenbank über einen ORA-Fehler mitgeteilt und sogar ein SQL Statement vorgeschlagen, das das konkrete Verbot aufhebt. Für unser JPA Programm sind nachfolgende Permissions nötig. Die Kommandos müssen von einem privilegierten Benutzer wie SYS oder SYSTEM ausgeführt werden oder von einem Benutzer mit JAVASYSPRIV Rolle. Einer der Parameter nennt offensichtlich den Benutzer-/Schemanamen, der die Permission erhalten soll – bitte tauschen Sie den „USERNAME“ aus gegen Ihren Datenbank-Benutzer.   call dbms_java.grant_permission( 'USERNAME', 'SYS:java.lang.RuntimePermission', 'getClassLoader', '' ) call dbms_java.grant_permission( 'USERNAME', 'SYS:java.util.PropertyPermission', '*', 'read,write' ); call dbms_java.grant_permission( 'USERNAME', 'SYS:java.lang.RuntimePermission', 'accessDeclaredMembers', '' ); call dbms_java.grant_permission( 'USERNAME', 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '' ); Insbesondere notwendig ist Zugriffserlaubnis für alle benötigten Entity-Klassen, die im Framework als Stream eingelesen werden. Obacht bitte, der zu tauschende „USERNAME“ taucht hier zweimal auf:   call dbms_java.grant_permission( 'USERNAME', 'SYS:oracle.aurora.rdbms.HandlePermission', 'HandleInputStream.USERNAME:com.ichag.simplejpa.Workers', 'read' )   Bei vielen Java Permissions sind auch Wildcards wie „*“ erlaubt. Alternativ könnte man auch schreiben:   call dbms_java.grant_permission( 'USERNAME', 'SYS:oracle.aurora.rdbms.HandlePermission', 'HandleInputStream.USERNAME:com.ichag.simplejpa.*', 'read' )   6) Aufruf des Programms und (debug)-output   Nun ist es endlich soweit, der Code ist geladen, die Tabelle angelegt, Berechtigungen vergeben, Stored Procedure erzeugt. Nun können wir einen Aufruf wagen und hoffentlich funktioniert auch alles:   set serveroutput on call dbms_java.set_output(50000); call getworkersjpa('dummy'); Sowohl die Ergebnis-Meldung “6” als auch alle Stack Traces und Exceptions im Fehlerfall werden direkt im SQL-Tool, z.B. SQL*Developer, ausgegeben. Zusätzlicher Output landet im .TRC File der Datenbank zur zugehörigen Datenbank-Session. .TRC Inhalte können auch remote via SQL ausgelesen werden, das beschreibt auch schön ein Blog Beitrag meines Kollegen Marcus Schröder: https://blogs.oracle.com/coretec/datenbank-tracing-%c3%bcbers-hintert%c3%bcrchen-oder-wie-komme-ich-ohne-betriebssystem-zugriff-an-meine-trace-files   SELECT timestamp, payload, trace_filename FROM v$diag_trace_file_contents ORDER BY timestamp DESC; Fertig ! Viel Spaß beim Testen und Ausprobieren, gerne versuche ich mich auch an Ihrem Code bzw. Ihrer Fehlermeldung !   7) Optional – setzen von System Properties Falls Sie in die Verlegenheit kommen, Ihren geladenen Code über sogenannte „System Properties“ zu konfigurieren gibt es auch innerhalb der Oracle Datenbank die Möglichkeit dazu. Diese Einstellung ist (nur) auf Session-Ebene möglich bzw. gültig, also z.B. über einen Login Trigger oder im SQL Skript, das den Ladejob oder das jeweilige Java Programm startet. Ein Beispiel:   select dbms_java.set_property('eclipselink.archive.factory', 'com.oracle.jpa.custom.OJVMArchiveFactoryImpl') from dual; select dbms_java.get_property('eclipselink.archive.factory') from dual; Es war zu Testzwecken in meinem Beispiel nötig, das Laden der Persistenz-Archive zu verfolgen und zu sehen, welche Dateien und über welche URLs sie geladen wurden. Dazu kann man bei EclipseLink eine eigene „ArchiveFactoryImpl“ anhängen. Das Feature wird z.B. beim WildFly Applikationsserver genutzt, weil dieser neben Dateiystem- und HTTP-Zugriffen auch ein eigenes internes „vfs“ Dateisystem benutzt. Die URLs zu den Java-Klassen und -Ressourcen innerhalb einer Oracle Datenbank folgen übrigens dem Schema „jserver: /resource/schema/<Benutzername>/<pfad-zur-ressource>“, also z.B. „jserver: /resource/schema/JAVA_POC/META-INF/persistence.xml“   8) Optional – setzen von Memory Parametern Die typischen Java Parameter „-Xmx“ und „-Xms“ zum Setzen des Java Speichers gibt es innerhalb einer Oracle Datenbank nicht in dieser Form. Die Oracle Datenbank übernimmt die Speicher-Zuteilung selbständig. Im Härtefall können Sie den maximalen Speicher für Java-Klassen und -Instanzen als Datenbank-Parameter eigenhändig setzen. Dieser lautet „JAVA_POOL_SIZE“ und steht normalerweise auf „0“, d.h. automatische Zuordnung. Es gibt auf github ein schönes Beispiel-Programm als Java Stored Procedure, das die aktuelle Java-Speicherbelegung einer Datenbank-Session darstellen kann: https://github.com/oracle/oracle-db-examples/blob/master/java/ojvm/memtest.sql   9) Optional – Debugging von Java Stored Procedures Auch das ist natürlich möglich! Mit einem herkömmlichen Debug-Tool für Java kann eine Debug-Session zur Datenbank aufgebaut werden. Dazu ist innerhalb der Datenbank per SQL die Debug session zu starten, die aktiv auf einen wählbaren Port eines lauschenden Debuggers zugreift. Bevor man das tun darf, sind Benutzer-Berechtigungen zu erteilen und eine Access-Control-List zu befüllen, die den Zugriff der Datenbank auf den Debug-Rechner erlaubt. Eine schöne Beschreibung hierzu bietet unsere Dokumentation: https://docs.oracle.com/en/database/oracle/oracle-database/18/jjdev/debugging-Java-stored-procedures.htm    

Das „Warum“ ist schnell geklärt: Hauptsächlich dient dies zur Beschleunigung der Interaktion von Java-Programmen mit der Datenbank durch drastische Reduzierung der Latenz-Zeiten. Je häufiger ein Java...

Einstieg

Oracle Cloud: Blueprints, Patterns und Infrastructure as Code

Die sogenannte Oracle Cloud Infrastructure wurde 2016 mit den klassischen Infrastructure as a Service Diensten gestartet. Seitdem wurden viele weitere IaaS, PaaS und SaaS Dienste in über 26 Cloud-Regionen weltweit bereitgestellt. Dank der umfangreichen Funktionalität können hochverfügbare, sichere und modernste Cloud-Anwendungen erstellt, konfiguriert bzw. genutzt werden. Die umfangreiche Dokumentation im Web beschreibt je Service dessen Funktionalitäten. Um einen schnelleren und leichteren Einstieg zu ermöglichen hat Oracle ein sogenanntes Architecture Center mit Referenzarchitekturen, Quick-Starters, Solution Playbooks, Getting-Started Anleitungen, Self-Learnings und Blogs bereitgestellt. Der zentrale Link über den die Themen erreichbar sind ist: https://www.oracle.com/cloud/architecture-center.html Darüber hinaus gibt es eine weitere step-by-step Beschreibung um mit der Oracle Cloud in das Thema Infrastructure as Code einzusteigen und dieses dann für eine echte Umsetzung als Basis weiterverwenden zu können. Dabei werden die OCI Basismodule verwendet, die es erlauben komplexe Enterprise Architekturen aufzubauen und zu verwalten. Es kommen die bekannten Werkzeuge wie terraform, packer, git usw. zum Einsatz. Ausprobieren lässt sich das auch mit dem sogenannten FreeTier, einer kostenfreien Testumgebung siehe https://www.oracle.com/de/cloud/free/ . Als Basis kann die darin enthaltene Cloud Shell genutzt werden so dass außerhalb der Cloud keine Installation von Werkzeugen oder Umgebungen erforderlich ist.  Der Link zur entsprechenden Beschreibung und zum Repository folgt hier.

Die sogenannte Oracle Cloud Infrastructure wurde 2016 mit den klassischen Infrastructure as a Service Diensten gestartet. Seitdem wurden viele weitere IaaS, PaaS und SaaS Dienste in über 26...

CloudDev

Oracle Cloud Infrastructure Shell - Das Browser-Terminal

Seit kurzem ist die Oracle Cloud Infrastructure Cloud Shell verfügbar. Der folgende Artikel gibt Anwendungsbeispiele und Hintergrundinformationen zur Cloud Shell. Anhand von drei einfachen Beispielen wird das schnelle und unkomplizierte Arbeiten mit der Cloud Shell verdeutlicht. Was ist die Cloud Shell? Die Oracle Cloud Infrastructure (OCI) Shell ist ein browser-basierendes Terminal-Fenster, das Zugriff auf eine Linux-Shell gewährt. Die Shell wird unten im OCI-Fenster angezeigt und man kann trotz geöffneter Shell in der OCI-Konsole navigieren.  Vorteil an dieser Stelle: Man bekommt eine Shell in der man als aktueller Benutzer eingeloggt ist und auf die OCI-Umgebung zugreifen kann. Dieser Benutzer besitzt die gleichen Rechte und Policies wie der Benutzer, mit dem man sich im Browserfenster angemeldet hat. Zentrale Administrative Tätigkeiten können so auf der Shell durchgeführt werden, ohne eine aufwendige Konfiguration/Port-Freischaltung bei Desktop-Terminals.  Limits und Kosten Die Basis-Service-Limits der Cloud Shell liegen bei einem Pay-as-you-Go Account bei 50 Benutzern und einer Gesamtnutzung von 240 Stunden. Bei Monthly Flex liegen die Limits bei 75 Benutzern und 400 Stunden Nutzung. D.h. innerhalb dieser Limits entstehen keine weiteren Kosten.  Wichtig! Die Cloud Shell ist in den Always-Free-Accounts nicht vorhanden! Hintergrund ist die Nutzung zusätzlicher Compute-Ressourcen, die durch die Cloud Shell Instanz entstehen. Daher ist die Cloud Shell nur den Bezahl-Accounts vorbehalten.  Implementierung Die Cloud Shell ist als Docker-Image implementiert. Wenn Sie die Cloud Shell im Browser-Fenster aktivieren, wird das Docker-Image gestartet und steht nach kurzer Zeit zur Verfügung. Das Docker-Image hat ein 5GB großes Volume im Home-Verzeichnis. Wenn Skripte/Dateien etc. im Home-Verzeichnis gespeichert werden, sind diese auch nach Beenden beim nächsten Start verfügbar.   Das Docker-Image liegt nicht innerhalb des Benutzer-Tenants, d.h. die Tenant-Limits etc. werden durch die Nutzung der Cloud-Shell nicht beeinflusst. Bevor eine Gruppe von Benutzern auf die Cloud Shell zugreifen kann, muss die entsprechende Policy in der OCI angelegt werden. Die Policy lautet:  allow group <GRUPPEN-NAME> to use cloud-shell in tenancy Das Time-Out der Cloud Shell liegt bei 20 Minuten Inaktivität und das maximale Session-Time-Out liegt bei 24 Stunden. Dies sollte man berücksichtigen, bevor zum Beispiel Cron-Jobs angelegt werden und man sich anschließend wundert, warum diese nicht ausgeführt wurden. Tools Die Cloud Shell unterstützt folgende Tools: OCI CLI Git Java Python (2 und 3) SQL*Plus kubectl helm maven gradle terraform Dies bedeutet, es kann alles aus der Cloud Shell gemacht werden, was auch aus einem Terminal-Fenster bzw. aus einer Development-Instanz innerhalb der OCI gemacht werden kann.  Beispiele:  Hochfahren und Anhalten von einer/mehreren OCI Ressourcen (Datenbanken, Compute-Instanzen, etc.) Ausführen von Terraform-Skripten in dem OCI-Tenant Aufrufen von Datenbank-Verbindungen und Ausführen von SQL*Plus Befehlen/Skripten Ausführen von Python-Skripte, Java-Programmen, etc. Steuern der Kubernetes-Cluster mittels kubectl Erstellen und Bereitstellen von Maven-Projekten Bereitstellen von Builds aus einem Git-Repository uvm. Verbindungen Mit der Cloud Shell kann auf das Internet zugreifen Der umgekehrte Zugriff - vom Internet auf die Cloud Shell - ist allerdings nicht möglich. Die Cloud Shell besitzt keine privaten Zugriffrechte auf den Tenant: Private Ressourcen innerhalb des Tenants sind damit nicht mit der Cloud Shell bedienbar. D.h die privaten Ressourcen innerhalb der OCI bleiben privat und können mit der Cloud Shell nicht "umgangen" werden.  Beispiel für die Anwendung der Cloud Shell 1.) Öffnen der Cloud Shell Wenn ausreichend Rechte vorhanden sind, kann man durch Klicken auf das Cloud Shell Icon oben rechts die Shell öffnen.  Bild: Öffnen der Cloud Shell innerhalb des Browser-Fensters. Das Öffnen kann ein paar Sekunden dauern, da bei längerer Benutzung die Docker-Instanz neu gestartet werden muss. Hat man die Cloud Shell vor kurzem gestartet, geht es viel schneller. Das Cloud Shell Fenster kann man maximieren und minimieren, Schrift-art und -Größe und den Hintergrund verändern.  2.) Abfragen des aktuellen Tenants Um herauszufinden wie der aktuelle Tenant bezeichnet wird, an dem man angemeldet ist, reicht es ohne weitere Konfiguration die OCI CLI zu verwenden. Mit dem Befehl: oci os ns get bekommt man den aktuellen Tenant angezeigt.  Bild: Abfrage des aktuellen Tenants.  3.) Verbindung zu einer Datenbank mittels SQL*Plus Für diese Verbindung wird der bereits installierte Instant-Client verwendet. Um es etwas einfacher zu machen erzeugen wir eine tnsnames.ora Datei und legen diese im Home-Verzeichnis-Pfad des aktuellen Benutzers ab, anschließend geben wir den Pfad mittels export TNS_ADMIN=/Pfad_zur_tnsnames_ora bekannt. Wichtig an dieser Stelle ist, dass die tnsnames.ora im Verzeichnis-Pfad des Benutzers liegt, da sie nur an dieser Stelle persistent abgelegt werden kann. Anschließend rufen wir mit sqlplus /nolog und einem connect username/password@SID die Verbindung auf. Natürlich können nur Verbindungen geöffnet werden, die auch über das Internet erreichbar sind, da die Cloud Shell nicht auf OCI Ressourcen zugreifen kann, die in einem privaten Netzwerk liegen.  Bild: Aufruf einer SQL*Plus Verbindung  Fazit Die OCI Cloud Shell ist ein sehr effizientes Hilfsmittel, wenn es um die zeilenorientierte Administration der OCI Ressourcen geht. Die Vielzahl von vorhandenen Tools ermöglicht es Administratoren und Entwicklern eine Reihe von Aufgaben schnell und effizient durchzuführen. Man könnte sich natürlich auch alle Tools lokal auf den eigenen Rechner installieren oder den Oracle Cloud Infrastruktur Development Client aus dem OCI Marketplace installieren. Dies bedeutet jedoch ein größerer Aufwand und setzt voraus, dass man entweder immer Zugriff auf den Client hat oder eine zusätzliche Ressource in dem Cloud Tenant betreibt, der natürlich Kosten verursacht.  Weiterführendes Material: Cloud Shell Handbuch     

Seit kurzem ist die Oracle Cloud Infrastructure Cloud Shell verfügbar. Der folgende Artikel gibt Anwendungsbeispiele und Hintergrundinformationen zur Cloud Shell. Anhand von drei einfachen Beispielen...

Database Vault für Autonomous Database

Ab sofort steht eine weitere Sicherheitsmaßnahme für die Autonomous Database zur Verfügung. Neben den bisher eingesetzten Sicherheitstechnologien wie Database Service Firewall, Transparent Data Encryption, Lockdown Profiles, Unified Auditing und 2-Faktor Authentifizierung (Zertifikat + Passwort) besteht nun die Möglichkeit, Database Vault zum Schutz gegen hochprivilegierte Datenbankbenutzer zu verwenden. Gerichtet ist diese Schutzmaßnahme gegen die Möglichkeit eines unbefugten Zugriffs durch Infrastruktur-Administratoren auf Ihre Daten. Um den störungsfreien Betrieb einer Autonomous Database zu gewährleisten, müssen jedoch hochprivilegierte Zugriffe auf Ihre Autonomous Database möglich sein. Diese Zugriffe werden über sogenannte – Common User – durchgeführt. Common User können auf jede Autonomous Databases (PDB) innerhalb einer Container-Datenbank zugreifen. Hierunter fallen unter anderem die Datenbankbenutzer SYS und SYSTEM. Im Kontext von Autonomous Database wird ein weiterer hochprivilegierter Common User mit dem Namen - C##CLOUD$SERVICE - verwendet. Dieser Benutzer wird lediglich über eine API angesprochen und dient als Schnittstelle zwischen der Cloud Control Plane und der Autonomous Database. Der Betrieb selbst wird durch zahlreiche technische und organisatorische Maßnahmen gesichert, welche auch fortlaufend durch externe Audits überprüft und überwacht werden. Mit Database Vault können Sie nun in Ihrer Autonomous Database eine zusätzliche Schutzebene einziehen um zu verhindern, dass trotz aller umgesetzten Sicherheitsmaßnahmen kein unbefugter Zugriff auf Ihre Daten, zum Beispiel durch einen dieser Common User, erfolgen kann. Das Ganze lässt sich mit wenigen Kommandos umsetzen, wie das folgende Beispiel zeigt. Die Voraussetzung ist eine laufende Autonomous Database, zum Beispiel auch eine AlwaysFree. Diese kann eine Transaction Processing oder Data Warehouse Datenbank auf einer Shared oder Dedicated Umgebung. Dedicated ist bei AlwaysFree nicht möglich. Zusätzlich wird das Schema (HR_DATA) benötigt, welches wir vor dem Zugriff durch Infrastruktur-Administratoren - wie zum Beispiel SYS und SYSTEM - schützen möchten. Nach dem Anlegen einer Autonomous Database melden wir uns mit dem Database Administrator ADMIN  an. Bei Bedarf vorab das Schema HR_DATA inklusive Objekte anlegen.  Zuerst überprüfen wir den Status von Database Vault. set linesize window col STATUS format a20 col PDB_NAME format a25 col DV_FEATURE format a20 SELECT B.NAME as PDB_NAME, A.NAME as DV_FEATURE, A.STATUS FROM CDB_DV_STATUS A, V$CONTAINERS B where A.CON_ID=B.CON_ID; PDB_NAME                                       DV_FEATURE                     STATUS -------------------------                            --------------------                      -------------------- RPLKBZT5W7YLXAQ_ADBDV        DV_APP_PROTECTION      NOT CONFIGURED RPLKBZT5W7YLXAQ_ADBDV        DV_CONFIGURE_STATUS  FALSE RPLKBZT5W7YLXAQ_ADBDV        DV_ENABLE_STATUS         FALSE In dieser Abfrage sehen wir, dass Database Vault weder konfiguriert noch aktiviert ist. Dies ist auch der Auslieferungszustand der Autonomous Database. Um Database Vault zu konfigurieren und zu aktivieren, muss ein PL/SQL Package namens DBMS_CLOUD_MACADM verwendet werden. Dies unterscheidet sich zwischen einer Nicht- Autonomous Database von einer Autonomous Database. Bei einer Nicht- Autonomous Database wird die PL/SQL Prozedur DVSYS.CONFIGURE_DV dazu verwendet. Diese Prozedur kann in einer Autonomous Database nicht verwendet werden, da sie nur durch einem Datenbankbenutzer mit SYSDBA Rechten ausgeführt werden kann und dieses Recht in einer Autonomous Database dem ADMIN Benutzer nicht zur Verfügung steht. Deswegen verwenden wir jetzt das PL/SQL Package DBMS_CLOUD_MACADM. In diesem PL/SQL Package befinden sich die Prozeduren CONFIGURE_DATABASE_VAULT, ENABLE_DATABASE_VAULT und DISABLE_DATABASE_VAULT. Zum Konfigurieren von Database Vault verwenden wir die Prozedur CONFIGURE_DATABASE_VAULT. Diese Prozedur erfordert die Angabe von zwei Datenbankbenutzern, welche im Nachgang die Rollen des Database Vault Owners und des Database Account Managers übernehmen. Diese Benutzer müssen vorab erstellt werden. Wir verwenden hier DVO als Database Vault Owner und DVAM als Database Account Manager. Der Benutzer ADMIN kann dafür nicht verwendet werden. GRANT CREATE SESSION TO dvo IDENTIFIED BY "Feuerwehr#112"; Grant succeeded. GRANT CREATE SESSION TO dvam IDENTIFIED BY "DiePolizei#110"; Grant succeeded. Jetzt kann Database Vault in der Autonomous Database konfiguriert werden. Dies muss mit dem Benutzer ADMIN durchgeführt werden. EXEC DBMS_CLOUD_MACADM.CONFIGURE_DATABASE_VAULT(dvowner_uname     => 'DVO', dvacctmgr_uname   => 'DVAM'); PL/SQL procedure successfully completed. Nachdem die Konfiguration erfolgreich durchgeführt wurde, können wir Database Vault aktivieren. Dies wird mit der Prozedur ENABLE_DATABASE_VAULT gemacht. Der Prozeduraufruf erfordert keine weiteren Angaben. EXEC DBMS_CLOUD_MACADM.ENABLE_DATABASE_VAULT; PL/SQL procedure successfully completed. Nachdem auch diese Prozedur erfolgreich durchgeführt wurde, muss die Autonomous Database über die Cloud Konsole neu gestartet werden. Sobald die Datenbank wieder verfügbar ist, melden wir uns mit dem ADMIN Benutzer an und überprüfen den Database Vault Status erneut. set linesize window col STATUS format a20 col PDB_NAME format a25 col DV_FEATURE format a20 SELECT B.NAME as PDB_NAME, A.NAME as DV_FEATURE, A.STATUS FROM CDB_DV_STATUS A, V$CONTAINERS B where A.CON_ID=B.CON_ID; PDB_NAME                                      DV_FEATURE                       STATUS -------------------------                            --------------------                       -------------------- RPLKBZT5W7YLXAQ_ADBDV        DV_APP_PROTECTION       NOT CONFIGURED RPLKBZT5W7YLXAQ_ADBDV        DV_CONFIGURE_STATUS  TRUE RPLKBZT5W7YLXAQ_ADBDV        DV_ENABLE_STATUS         TRUE Wie hier zu sehen ist, ist Database Vault nun in der Autonomous Database aktiviert und einsatzbereit. Das Verwalten der Database Vault Sicherheitsrichtlinien kann nun über Oracle Cloud Control 13.4 durchgeführt werden oder mittels des PL/SQL Package DVSYS.DBMS_MACADM über SQL*Plus durchgeführt werden. Weitere Informationen über das PL/SQL Package DVSYS.DBMS_MACADM finden Sie hier. Im folgendem Beispiel werden wir das Schema HR_DATA, welches vorab angelegt wurde, vor dem Zugriff durch SYS beziehungsweise SYSTEM schützen. Als Erstes überprüfen wir, ob ein Benutzer mit DBA Rechten auf die Daten zugreifen kann. Da wir SYS und SYSTEM nicht verwenden können, führen wir diesen Test mit dem ADMIN Benutzer durch. Die Wirkung ist dabei dieselbe, da der ADMIN Benutzer wie SYS und SYSTEM auch über ein SYSTEM Privileg – SELECT ANY TABLE – zugreift.  select count(*) from hr_data.demo_hr_employees;  COUNT(*)  -----------           62 Jetzt legen wir einen Database Vault REALM mit dem Namen HR_DATA an. exec DVSYS.DBMS_MACADM.CREATE_REALM(realm_name => 'HR_DATA', description => 'PII Data', enabled => 'Y', audit_options => '1'); PL/SQL procedure successfully completed. Wurde das erfolgreich durchgeführt, beschreiben wir welche Objekte mittels dieses Realms geschützt werden sollen. Im Beispiel werden alle Objekte innerhalb des Schemas HR_DATA geschützt. exec DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM(realm_name => 'HR_DATA', object_owner => 'HR_DATA', object_name => '%', object_type => '%'); PL/SQL procedure successfully completed. Damit sind wir auch im Prinzip bereits fertig. Von jetzt an, kann kein Datenbankbenutzer mittels eines System-Privileges mehr auf Objekte innerhalb des Schemas HR_DATA zugreifen.           select count(*) from hr_data.demo_hr_employees; ERROR at line 1: ORA-01031: insufficient privileges In diesem Beispiel wurde gezeigt, wie einfach sich Daten vor dem Zugriff hochprivilegierter Datenbankbenutzer in der Autonomous Database schützen lassen. Alle Eigenschaften von Database Vault stehen kostenfrei in der Autonomous Database zur Verfügung.   Um den Schütz des Schemas wieder zu entfernen einfach folgenden Befehl verwenden. exec DVSYS.DBMS_MACADM.DELETE_REALM(realm_name => 'HR_DATA'); Um Database Vault zu deaktivieren einfach diesen Befehl als ADMIN beziehungsweise DVO ausführen.           exec DBMS_CLOUD_MACADM.DISABLE_DATABASE_VAULT; Die Autonomous Database durchstarten und alles ist wieder wie vorher. Database Vault kann aber wesentlich mehr. Wenn Sie zum Beispiel die Vergabe von Rollen schützen wollen, müssen Sie einfach einen weiteren Realm anlegen und dort entsprechende Rollen bekannte geben. Kleiner Hinweis: Alle Rollen gehören dem SYS Benutzer.  Weitere Informationen Die Dokumentation und gute Beispiele dazu finden Sie im Oracle Database Vault Administrator's Guide. Weitere Informationen zum Thema Autonomous Database und Database Vault finden Sie hier: Using Oracle Database Vault with Autonomous Database Lizenzen Für die Verwendung von Database Vault in der Autonomous Database ist keine zusätzliche Lizenz notwendig. Genauso wie bei den Oracle Database Cloud Services ab Enterprise Edition - High Performance   Viel Erfolg beim Testen.  

Ab sofort steht eine weitere Sicherheitsmaßnahme für die Autonomous Database zur Verfügung. Neben den bisher eingesetzten Sicherheitstechnologien wie Database Service Firewall, Transparent Data...

Sicherheit

Vorgeschaltete Absicherung mit Oracle Edge Services

Abstract: Oracle Edge Services sind ein wesentlicher Baustein zur Verbesserung der Cyber- und IT-Sicherheit. Sie stellen eine zusätzliche vorgeschaltete Abwehrschicht dar und sichern die Oracle Cloud, andere Clouds und On-Premises Anwendungen. Sicherheitsbedrohungen wie DDoS, bösartige Bots und Cyberangriffe werden beim Zugriff analysiert und sobald erkannt auch mitigiert und bestenfalls ausgeschaltet. Edge Services stellen darüber hinaus auch die Verfügbarkeit und optimale Erreichbarkeit der Anwendungen sicher. Edge Services werden aus global verteilten Datacentern von Oracle, u.a. in Frankfurt, als "gemanagte Services" bereitgestellt. ie wesentlichen Bestandteile der Oracle Edge Services sind: Domain Name System (DNS), Abwehr von Denial of Service Angriffen (DDos), Web Application Firewall (WAF) und Monitoring des Internets (Internet Intelligence) und eigener Dienste. Diese Services werden kurz vorgestellt.   Die heutigen Herausforderungen in der Unternehmens-IT liegen nicht mehr nur in der Bereitstellung und Aktualisierung von digitalen Diensten, sondern auch in der Abwehr einer steigenden Anzahl und Intelligenz von Bedrohungen. In der Vergangenheit war die IT wie eine Festung innerhalb eines Rechenzentrums geschützt, ist heute aber durch die öffentliche Erreichbarkeit von digitalen Diensten im Prinzip den gleichen Herausforderungen wie ein Cloudanbieter ausgesetzt. Eine naheliegende Lösung zu Reduzierung von Kosten und Aufwänden für die Abwehr und Verfügbarkeit ist es, komplett in die Cloud zu wechseln und damit von den dort vorhandenen Optimierungs- und Schutzmaßnahmen zu profitieren. Gerade die Oracle Cloud bietet hier abgesicherte Umgebungen und Anwendungen - „security by default“ - und entsprechende Security Services. Vollständig in die Cloud passt natürlich nicht für jeden. In und mit der Cloud von Oracle und anderen Unternehmen haben sich allgemeine Muster herausgebildet, die sowohl für die Cloud als auch On-Premises verwendet werden können. Neben übergeordneten SIEM (Security Information Event Management) und CASB (Cloud Access Security Broker) Systemen sind das die sogenannten Edge Services. Edge Services sind im Prinzip der erste Kontaktpunkt für den Benutzer auf dem Weg zur Nutzung eines digitalen Dienstes. Geprägt wurde der Begriff durch die sogenannten CDNs (Content Delivery Netzwerk), die den Content physikalisch in Richtung Benutzer verlagern, um die Verfügbarkeit und Performance zu erhöhen.  Bevor ein CDN oder Content erreicht werden kann, muss über ein DNS der Dienstname, z.B. oracle.com in eine IP Adresse übersetzt werden. Ein DNS könnte auch ähnlich wie beim CDN ein Routing z.B. auf den nächstgelegenen gerade optimal erreichbaren Server durchführen. Dieser ist damit auch Bestandteil von Edge Services. Die Nutzung bietet unter anderem folgende Vorteile: Zusätzliche Schichten zur Abwehr: Edge Services ersetzen nicht die Sicherheit im/vom Rechenzentrum oder Cloud Service, sondern stellen eine vorgelagerte Schicht dar, die vor einem Zugriff aktiv sind Sicherheitsfunktionen wie DDos Abwehr, Web-Application Firewalling und Reaktion auf Routenumlenkungen Performance Beschleunigungen durch Loadbalancing, Caching, optimierte und schnelle DNS Auflösung und zeitnahe Umsetzung validierter Routenänderungen Automatische Entdeckung und Behandlung durch gleichzeitige Abdeckung von Angriffsvektoren auf verschiedenen Ebenen (Netzwerk, Benutzer/Bots, Anwendungen) Unterstützung für Workloads in einer oder mehreren Clouds und/oder On-Premises Informationen können in nachgelagerten Schichten für automatische Reaktionen genutzt werden Verwendung von Echtzeitinformationen aus dem Deep Monitoring des weltweiten Internets hinsichtlich Performance und Security Events. Oracle Edge Services werden aus global verteilten Edge Rechenzentren bereitgestellt, so dass eine örtliche und latenz-optimierte Nutzung möglich ist.  Die Edge Services sind gemanagte Cloud-Services von Oracle, die von Cyber-Security Spezialisten betrieben werden.   Abbildung: Oracle Edge Rechenzentren Die Edge Services in Deutschland kommen aus der Region Frankfurt. Weitere, nicht abgebildete Oracle Rechenzentren stellen die Oracle Cloud Services (IaaS, PaaS, SaaS) bereit. Diese Services haben folgende technischen Merkmale: DNS mit Ausfallsicherheit und Schutz vor DDoS-Angriffen durch globales Anycast-Netzwerk mit mehreren über Kontinente verteilten Rechenzentren und redundanten Tier-1 Anbindungen Berücksichtigung des aktuellen „Internet Health“ durch Analyse mit Hilfe von 600 Monitoring Punkten, das Leistungsabfälle, Änderungen beim Internet-Routing, Netzwerksicherheitswarnungen und DDoS-Schutzaktivierungen von DDoS-Anbietern auswertet WAF-Funktionen (native Web Application Firewall) zum Schutz auf Layer 4 und 7 sowie Regelwerken gegen Botnets, Cross Site Scripting, SQL Injection und DDoS-Angriffen Optimierung für die Erreichbarkeit und Latenz für Workloads in Clouds und On-Premises Health Checks von verschiedenen Punkten aus für eigene URLs um die Verfügbarkeit von Anwendungen und Services zu monitoren.   Werden alle Edge Services genutzt, findet zuerst eine DNS Steuerung bei der Auflösung der URL in eine IP statt. Der nächste Kontaktpunkt ist die WAF, die entsprechende Prüfungen vornimmt. Erfolgreiche Prüfungen der WAF lassen dann den Request auf den adressierten Server oder Loadbalancer, in der Cloud oder On-Premises, durch. Für das Monitoring stehen sowohl die Log-Informationen aus den aufgerufenen Services, der WAF und den „Health Checks“ zur Verfügung. Weiterführende Informationen werden über das Internet Health Dashboard bereitgestellt   Fazit Die stetig steigende Anzahl von digitalen Services und Content sowie die intelligenteren und häufigeren Angriffe stellen Unternehmen und öffentliche Verwaltungen vor die Herausforderung, schnell und angemessen zu reagieren. Auch im Bereich des Antwortzeitverhaltens sind Benutzer verwöhnt und akzeptieren zunehmend weniger Wartezeiten bei Serviceaufrufen. Verteilte Microservices bzw. Meshes potenzieren das Problem. Oracle stellt dazu mit den Edge Services essentielle Services für die Sicherstellung der Verfügbarkeit, Performanceoptimierung, DDoS Abwehr und Layer7 (u.a. OWASP) Mitigation zur Verfügung. Die Services sind zum Teil mehr als 10 Jahre in Produktion und werden von Oracle und SOC Spezialisten betrieben. Die browserbasierte Konfiguration erlaubt eine einfache Nutzung. Anlaufkosten sind durch die Bereitstellung als Service gering, Aufbaukosten entfallen. Über die Trials können die Services auch kostenfrei getestet werden.  Weiterführende Informationen: https://cloud.oracle.com/en_US/edge  

Abstract: Oracle Edge Services sind ein wesentlicher Baustein zur Verbesserung der Cyber- und IT-Sicherheit. Sie stellen eine zusätzliche vorgeschaltete Abwehrschicht dar und sichern die Oracle...

IaaSundPaaS

Quickstart: Oracle Secure Desktop Client für die Oracle Cloud Infrastructure

Wenn man einen zentralen und sicheren Zugriff auf Applikationen und Daten in der Oracle Cloud benötigt, hat man mit dem Oracle Secure Desktop Client (SGD) das richtige Werkzeug. Der SGD ist ein Produkt mit einer langen Oracle-Historie und kam ursprünglich aus dem Hause Sun. Der Desktop Client bietet eine Reihe von Vorteilen beim täglichen Umgang mit der Oracle Cloud Infrastructure, er bietet:  Ein zentralen und sicheren Fern-Zugriff auf die Oracle Cloud Infrastructure Unterstützung verschiedener Anwendungen und Desktops wie zum Beispiel SSH, RDP, X-Windows etc. Zugriff über Linux, Solaris, Windows, Mac, iOS und Android Persistente Sessions Bild: Oracle Secure Desktop Client Dieser Artikel dient als Quickstart-Guide und ermöglicht dem Leser die Basisfunktionen des SGD für die Oracle Cloud Infrastructure (OCI) einzurichten und zu nutzen. Der Guide unterteilt sich in die Bereiche SGD-Installation und Einrichten einer SSH- und einer Windows-Remote-Desktop-Protocol-Verbindung. 1. Installation des SGD in der OCI Die Installation ist einfach, da Oracle ein vorgefertigtes SGD-Image im Oracle-Cloud-Marketplace anbietet. Loggen Sie sich in die Oracle Cloud Infrastructure ein und erzeugen Sie in einem Public Virtual Cloud Network eine neue Compute Instanz. Unter dem Menüpunkt "Change Image Source" wählen Sie den Reiter "Oracle Images" und suchen nach der App "Oracle Secure Global Desktop". Alle restlichen Parameter können die Standard-Werte behalten. Erzeugen Sie anschließend die Instanz. Bild: Auswahl des Oracle Secure Global Desktop Nach der Fertigstellung der Compute Instanz gehen Sie auf die Detail-Ansicht. Im oberen Bereich der Instanz Informationen finden Sie den Schalter "View Usage Instructions". In der angezeigten Beschreibung sind alle Schritte aufgeführt, um auf den SGD-Client zu zugreifen.  Bild: Usage Instructions 2. Zentraler Zugriff auf Oracle Cloud Linux- und Windows-Instanzen Wenn man im Browser seiner Wahl die URL https://public-ip-der-sgd-instanz aufruft, kommt man auf die Homepage des SGD. Auf der statischen Homepage können verschiedene Aktionen durchgeführt werden: Administrations-Konsole aufrufen, Einloggen in den Workspace, Download der OS-Clients, Aufruf der Dokumentation etc..  Beim Aufrufen der Administrations-Konsole oder des Workspaces müssen ein Benutzername und ein Passwort eingegeben werden. Der Administrations-Benutzer ist "sgdadmin" und das initiale Admin-Passwort bekommt man wie in den "Usage Instructions" beschrieben. Um die Arbeitsweise des SGDs zu verstehen, müssen erst drei Begriffe erklärt werden. Die Basis-Begriffe im Umgang mit dem SGD stellen Application Server, Applications und Groups dar. Der Application Server ist an dieser Stelle der Host auf den zugegriffen werden soll. Die Application sind die Anwendungen, die auf den Host zugreifen soll. Hierbei handelt es sich zum Beispiel um ein SSH-Terminal oder eine Remote Desktop Verbindung auf eine Windows Instanz. Bei den Groups handelt es sich um Zuweisungen/Aufteilung von Applications in Gruppen. Für den Quickstart sind Groups wichtig, da wir die im nächsten Schritt neu erzeugten Applications der Group Application zuweisen müssen, damit sie im SGD-Client sichtbar wird. a.) Einrichten eines neuen Application Servers Zum Einrichten loggt man sich über https://public-ip-der-sgd-instanz auf die Administrations-Konsole ein, dafür wählen Sie den Link "Launch the Oracle Secure Global Desktop Administration Console". Der Benutzername ist auch an dieser Stelle "sgdadmin". Wählen Sie aus den oberen Reitern den Bereich "Application Servers" und klicken Sie in der Tabelle auf "New". Im Pop-Up-Fenster geben Sie als Namen den Hostname des gewünschten Ziel-Servers ein und setzen den Type auf "Application Server". Wenn man als Namen die Host-Adresse/IP eingibt wird diese automatisch mit der Ziel-Adresse verknüpft. Sie können hier den Full-Qualified-DNS-Name verwenden oder die IP Adresse eingeben. Der Name des Application Servers kann jederzeit geändert werden. Hinweis: Man kann die Adress-Auflösung in der Web-Oberfläche testen, dieser Test ist wird oft als nicht erfolgreich angezeigt, obwohl die Adresse erreichbar ist. Daher führe ich den Test nicht aus, nachdem ich die Ziel-Host-Adresse eingegeben habe. b.) Erzeugen von Applications Als nächstes werden zwei Applications erzeugt, ein SSH-Terminal zu einer Linux-Instanz und eine Windows Desktop Verbindung zu einer Windows-Instanz. Dafür gehen Sie in der Administrations-Konsole auf den Bereich "Applications". Wählen Sie in der Tabelle "New" und geben der Application einen Namen, zum Beispiel SSH-Client-XYZ, als Application-Type wählen Sie "Character Application". Wählen Sie anschließend die neu erzeugte Application und geben im Reiter "Launch" unter "Application Command" /usr/bin/bash ein. Dieser Eintrag sorgt dafür, dass die Command-Bash ausgeführt wird wenn Sie sich mit der Application an den Application Server anmelden. Um dieser Application einen oder mehreren Application Servern zu zuordnen gehen Sie auf den Reiter "Hosting Application Servers" und fügen Sie mittels "Add" den Linux-Application-Server zu.  Um die neue Application "sichtbar" zu machen navigieren Sie in der Administrations-Konsole in die Übersicht und wählen aus dem Reiter "Applications" die Group "Applications" aus. Unter Members fügen Sie mit "Add" die neu erzeugte Application SSH-Client-XYZ hinzu. Wenn Sie sich anschließend an der SGD-Konsole anmelden, sehen Sie auf der linken Seite die neu erzeugte Application und können sich so schnell und sicher auf den Linux-Client anmelden. Im Anmeldevorgang müssen Sie noch den Benutzer-Namen (opc) und den Pfad für das Private-Key-File angeben. Bild: SSH Zugriff auf einen Linux-Client per SGD Um auf den Windows Client zuzugreifen, sind im allgemeinen die gleichen Schritte notwendig, wie für den Linux Client mit der Ausnahme, dass man die Application als "Windows Application" erzeugt und das Feld "Application Command" im Reiter "Lauch" leer lässt. Noch ein wichtiger Tipp: Standardmäßig greift die Windows Application per Remote Desktop Protocol (RDP) zu, d.h. der Port muss in der Security List des Virtual Cloud Network der OCI freigeschaltet werden, hier ist beschrieben, wie man so etwas macht. Bild: Remote Desktop Zugriff auf einen Windows-Client per SGD 3. Fazit Die im Quickstart dargestellten Möglichkeiten stellen nur ein kleinen Ausschnitt der Gesamt-Funktionalitäten des Oracle SGD dar. Für weiterführende Literatur können Sie hier die Dokumentation aufrufen und hier die Oracle-Blog-Seite für den SGD. Für die zentrale und sichere Verwaltung von mehreren Oracle Cloud Servern, ist Secure Oracle Desktop das richtige Werkzeug. Es können Konfigurationen gespeichert und ohne großen Aufwand als Applications geöffnet werden. Da SGD jetzt im Oracle Marketplace als Image verfügbar gemacht wurde, ist die Installation und Konfiguration sehr schnell, man erstellt einfach eine neue Compute-Instanz. Weiterführende Links: SGD Homepage - https://www.oracle.com/de/secure-global-desktop/ SGD Dokumentation - https://docs.oracle.com/cd/E88357_01/index.html SGD Blog - https://blogs.oracle.com/virtualization/oracle-secure-global-desktop SGD Preise in Dollar (nach Secure Global Desktop suchen) - https://www.oracle.com/assets/technology-price-list-070617.pdf      

Wenn man einen zentralen und sicheren Zugriff auf Applikationen und Daten in der Oracle Cloud benötigt, hat man mit dem Oracle Secure Desktop Client (SGD) das richtige Werkzeug. Der SGD ist...

Sicherheit

Konfigurations- und Compliance Test mit einem Oracle Database Cloud Service

Dieser Blog wurde von der Gast Autorin Amalia Darie, Oracle erstellt. Es handelt sich um eine Testanleitung mit dem Configuration und Compliance Cloud Service um eine IT-Compliance mit einer Testdatenbank in nicht produktiven Umgebungen mit reinen Spieldaten zu überprüfen.  Oracle Management Cloud ist eine Lösung mit integrierten Monitoring-, Management- und Analyse-Cloud-Services, die Machine Learning und Big Data-Techniken nutzt. Der Oracle Configuration and Compliance Service ermöglicht dabei die angeschlossenen Services, wie z.B. Oracle Datenbanken, hinsichtlich der IT- und Business Compliance zu monitoren und Abweichungen festzustellen oder auch zu beheben. Die enthaltenen Regelwerke basieren auf branchenüblichen Benchmarks wie PCI-DSS und Best Practices von Oracle. Benutzerdefinierte Regeln können zusätzlich definiert werden. Der Oracle Configuration and Compliance Service kann sowohl für On-Premises Installationen als auch für Cloud-Infrastrukturen (Oracle und 3rd Party) verwendet werden. Dieses Dokument hat als Ziel den Oracle Configuration and Compliance Service mit einer Oracle Datenbank in einer Spielumgebung auszuprobieren. Der nachfolgende Screen zeigt ein beispielhaftes Ergebnis einer größeren Umgebung: Abb 1: Beispielhaftes Ergebnis Voraussetzung für dieses Tutorial ist sowohl eine Oracle Management Cloud (im folgenden OMC) als auch eine Cloud  Datenbank (DBCS) Instanz. Diese können im Rahmen eines Oracle Cloud Trials, der im Web eröffnet werden kann, angelegt werden.  Folgende Schritte werden im Rahmen des Tutorials durchgeführt: Herunterladen der Oracle Management Cloud-Agent Software Erstellen des Registrierungsschlüssels für den Cloud-Agent Installation des Cloud-Agents Definieren der SSH-Host Anmeldeinformationen für den Cloud-Agent Definieren der Oracle-Datenbank-Anmeldeinformationen für den Cloud-Agent Hinzufügen der Datenbank-Entität Evaluierung der Oracle Datenbank Cloud Service-Instanz Analyse der Compliance Ergebnisse Remediation bzw. Behebung von Abweichungen   HERUNTERLADEN DER ORACLE MANAGEMENT CLOUD-AGENT SOFTWARE    Der Cloud-Agent muss auf dem Betriebssystem der Datenbank installiert und konfiguriert werden. Die einfachste Methode zum Herunterladen der Installationssoftware für den Cloud-Agent ist die Verwendung des Oracle Management Cloud User Oberfläche. Folgende Schritte sind dazu notwendig:   1. Bitte auf der Startseite der Oracle Management Cloud auf das Symbol OMC Navigation oben links klicken, um den Navigationsbereich der Management Cloud anzuzeigen, falls er nicht bereits angezeigt wird.   2. Unter Verwaltung die Option Agents auswählen. Dann wird die Seite Oracle Management Cloud Agents angezeigt.   3. Auf der Seite Oracle Management Cloud Agents auf das Aktionsmenü   oben rechts auf der Seite klicken und „Download Agents“ auswählen. Die Seite für das Herunterladen der Agent Software wird angezeigt.   4. Den Agent-Typen Cloud-Agent aus der Dropdown-Liste Agent Typ selektieren und das Betriebssystem aus der Dropdown-Liste Betriebssystem auswählen, auf dem der Agent installiert werden soll. Der Link zur Agent-Software für den von Ihnen ausgewählten Agent wird angezeigt.   5. Auf den Link Agent Software klicken, um die ZIP-Datei der Agent Software herunterzuladen.   Abb. 2: Download Agent     ERSTELLEN DES REGISTRIERUNGSSCHLÜSSELS   Um den Oracle Management Cloud-Agent zu installieren wird ein Registrierungsschlüssel benötigt. Ein Registrierungsschlüssel wird für die aktuelle OMC Instanz erstellt. Dieser Schlüssel wird im Parameter AGENT_REGISTRATION_KEY=<NewKeyValue> angeben. Der Registrierungsschlüssel wird nur während der Installation verwendet. Sobald ein Agent mit dem Registrierungsschlüssel installiert wurde, kann dieser Schlüssel aus der Oracle Management Cloud entfernt werden.   Um einen Registrierungsschlüssel zu erstellen, müssen die folgenden Schritte durchgeführt werden: 1. Auf der Startseite der Oracle Management Cloud auf das globale Navigationsmenü oben links klicken und dann auf Agent unter Administration. Die Seite Oracle Management Cloud Agents wird angezeigt.  2. Auf der Seite Oracle Management Cloud Agents auf das Aktionsmenü   oben rechts auf der Seite klicken und Registrierungsschlüssel verwalten auswählen. Auf der Seite Registrierungsschlüssel wird eine Liste aller Registrierungsschlüssel angezeigt.  3. Folgende Angaben auf der Seite Registrierungsschlüssel sind notwendig:  a. Namen des Registrierungsschlüssels   b. Registration Limit als maximale Anzahl von Agents, Data Collectors und Gateways die den  Registrierungsschlüssel verwenden können  c. Anschließend kann der Registrierungsschlüssel mit „Create New Key“ erzeugt werden   Die folgende Abbildung zeigt einen erstellten Registrierungsschlüssel: Abb. 3: Registrierungsschlüssel   INSTALLATION DES CLOUD-AGENTEN  Es wird empfohlen nicht den Root-Benutzer für die Installation von Cloud-Agents zu verwenden. Der Cloud-Agent wird installiert, indem das Skript AgentInstall über die Befehlszeile ausgeführt wird. Das Skript liest einen Satz von Parametern, die in einer Datei (agent.rsp) angegeben oder in der Befehlszeile übergeben werden können.  Eine typische Installation geht davon aus, dass die Antwortdatei agent.rsp im selben Verzeichnis gespeichert ist, in dem das Agentinstall Skript gespeichert ist. Wenn dies nicht der Fall ist, muss der Parameter AGENT_RSP_FILE in der Befehlszeile mit dem Pfad der Parameterdatei beim Aufruf übergeben werden.  Die Parameterdatei benötigt mindestens folgende gelb markierte Informationen aus der OMC Oberfläche: Abb. 4: Benötigte Angaben Teil 1 Abb. 5: Benötigte Angaben Teil 2   Übertragene Werte in der Parameterdatei: Der Cloud-Agent wird nun ohne zwischengelagertes Gateway installiert und benötigt dazu einen Internetzugang, entweder direkt oder über einen Proxy-Server. Es muss nur das Installationsskript ausgeführt werden. Weitere Details zur typischen Installation eines Cloud-Agent finden Sie hier: Die Installation kann anschließend über die Oracle Management Cloud Oberfläche überprüft werden:  Abb. 6: Installierte Cloud Agents Abb. 7: Installierter Cloud Agent   Es kann auch über die Command-line ein omcli-Befehl aus dem Verzeichnis <AGENT_BASE_DIRECTORY>/agent_inst/bin verwendet werden, um zu überprüfen, ob der Cloud-Agent erfolgreich bereitgestellt wurde:   DEFINIEREN DER SSH-HOST-ANMELDEINFORMATIONEN   Zunächst wird der Credential Store konfiguriert und die SSH-Host Anmeldeinformationen hinzugefügt. In einem nächsten Schritt erfolgt das auch für die Datenbank.    Bevor Sie mit der Konfiguration der SSH-Host-Anmeldung beginnen muß eine JSON-Datei, z.B. cred.json, wie folgt erstellt werden:      Option 1: SSH-Schlüssel (empfohlen)   [   {     "entity": "omc_host_linux.<HOST_NAME>",     "name": "omc_oracle_<HOST_NAME>-HostSSHCreds",     "type": "HostSSHCreds",     "globalName": "emcosComplianceCred",     "description": "SSH Credential for the agent omcagentuser",     "properties": [      { "name":"USERNAME", "value":"CLEAR[omcagentuser]" },      { "name":"SSH_PVT_KEY", "value":"FILE[<YourUsername>/.ssh/id_rsa]" },      { "name":"SSH_PUB_KEY", "value":"FILE[<YourUsername>/.ssh/id_rsa.pub]" }    ]   }         ] Option 2: Passwort [   {     "entity":"omc_host_linux.<HOST_NAME>",     "name":"<HOST_NAME>-HostSSHPwdCreds",     "type":"HostSSHPwdCreds",     "globalName":"emcosComplianceCred",     "description":"SSH Credential for the host entity",     "properties":[       { "name":"USERNAME", "value":"CLEAR[YourUsername]"},       { "name":"PASSWORD", "value":"CLEAR[YourPassword]"}     ]   }         ]   Mit folgenden Werten: • HOST_NAME ist der voll qualifizierte Name Ihres Hosts. Zum Beispiel: host1.example.com  • Name ist ein beliebiger Name für Ihre Anmeldeinformationen. Wir empfehlen, dass Sie diese Anmeldeinformationen Ihren Hostnamen gefolgt von HostSSHPwdCreds benennen. Zum Beispiel: host1.example.com-HostSSHPwdCreds.  • Der „globalName“ der Anmeldeinformationen muss der reservierte Wert „emcosComplianceCred“ sein.  • „YourUsername“ ist der Benutzername, der als SSH-Anmeldeinformationen verwendet wird.  • „YourPassword“ ist das Passwort für Ihre SSH-Anmeldeinformationen.  • Alle anderen Feldwerte müssen wie aufgelistet bleiben, diese sind reservierte Werte. Erstellen der SSH-Host-Anmeldeinformationen wie folgt: 1. Anmeldung als der Benutzer an, der den Agent installiert hat.   2. Wechseln in Installationsverzeichnis, z.B. <AGENT_BASE_DIR>/agent_inst/bin   3. Stoppen des Agents: $ Omcli stop agent   4. Konfiguration des Agents so dass ein Wallet-basierten Credential Store verwendet wird. $ omcli add_credential_store agent - no_password 5. Starten des Agents: $ omcli start agent 6. Anmeldedaten dem Credential Store hinzufügen: $ omcli add_credentials agent -credential_file cred.json     7. Überprüfen der hinterlegten Anmeldeinformationen   DEFINIEREN DER ORACLE DATABASE-ANMELDEINFORMATIONEN   Oracle Configuration and Compliance verwendet automatisch die Datenbank-Anmeldeinformationen, die vom Oracle Infrastructure Monitoring verwendet werden, wenn keine Datenbank-Anmeldeinformationen im Wallet des Agents angeben sind. Es wird empfohlen, dbsnmp (einen in der Oracle Database integrierten Benutzer) zu verwenden, da dieser Benutzer mit wenigen Ausnahmen standardmäßig über die erforderlichen Berechtigungen verfügt. 1. Öffnen eines Terminals auf dem Agent Host und suchen nach dem Paar <DB_NAME>, <entity_type>: $ omcli config agent listtargets Diese Informationen werden benötigt, um einen neuen Monitoring-Agent mit omcli hinzuzufügen.  2. Erstellen und speichern einer JSON-Datei mit den Zugangsdaten, z.B. test_db_cred.json: Wobei: • DB_NAME ist der Name Ihrer Datenbank, zum Beispiel: dbserver.example.com  • „Name“ ist ein beliebiger Name für Ihre Anmeldeinformationen. Als Best Practice kann beispielsweise die Anmeldeinformationen nach Ihrem Entitätstyp benannt werden, gefolgt von DB_NAME und DBUserCreds, z.B.: omc_oracle_db-dbserver.example.com-DBUserCreds • „YourUserName“ ist der Benutzername, der als DB-Anmeldeinformationen verwendet wird.  • „YourPassword“ ist das Passwort für Ihre DB-Anmeldeinformationen.  • Alle anderen Feldwerte müssen wie aufgelistet bleiben, diese sind reservierte Werte. 3. Anmeldedaten mithilfe der Datei test_db_cred.json dem Credential Store hinzufügen:   $ omcli add_credentials agent -credential_file test_db_cred.json 4. Überprüfung der hinterlegten Anmeldeinformationen:   $ omcli list_credentials agent Bevor die Datenbank mit Hilfe von sofort einsatzbereiten Regelsätzen (Out-of-the-box Rulesets) überwacht werden können, müssen dem überwachenden DB-Benutzer die folgenden Berechtigungen (Privileges) gewährt werden. Weitere Details zum Prozess der Definition der Oracle Database-Anmeldeinformationen finden Sie hier. HINZUFÜGEN DER DATENBANK-ENTITÄT Jetzt kann die Datenbank-Entität hinzugefügt werden, die überwacht werden soll. Diese können direkt in der Administrationskonsole in der Oracle Management Cloud im Bereich Entitäten hinzugefügt werden. Abb. 8: Hinzugefügte DB Entität   Abb. 9: Hinzugefügte DB Entität   Der nächste Schritt besteht darin, den License Edition Standard mit Configuration and Compliance zur neuen DB Entity hinzuzufügen. Abb. 10: DB Entitäten und aktivierte Lizenzen       EVALUIERUNG DER ORACLE DATABASE CLOUD SERVICE-INSTANZ   Über Assessment Templates wird definiert welche Benchmarks (Standardregelsätze), eigene Regelsätze und Cloud-Ressourcen, evaluiert werden. Dazu muss ein Template wie folgt erstellt werden:   1. Im Menü Assessments wählen und auf Vorlagen klicken. 2. Hinzufügen klicken und einen Namen und eine Beschreibung für das Assessment Template vergeben. 3. Auswählen der Regeln der aufgelisteten Benchmarks (industry-standard benchmark rules), die geprüft werden sollen. 4. Hinzufügen der Objekte, für die Sie die ausgewählten Regelsätze angewendet werden sollen. 5. Auswahl eines Zeitplans und abschließendes Speichern.   Abb. 11: Definition Assessment - Regelsätze Abb. 12: Definition Assessment – DB Entitäten   Abb. 13: Definition Assessment - Abschluß   ANALYSIEREN DER COMPLIANCE-ERGEBNISSE Oracle Configuration and Compliance verwendet einen Compliance Score, um eine Kurzbewertung über die Konformität zu erhalten. Der Bereich „Assessment - Run Detail“ bietet einen Überblick über den Compliance Lauf.  Auf der Seite Assessment - Run Detail finden Sie die folgenden Informationen: 1. Assessment Name and Details - Laufzeit, Anzahl der ausgeführten Regelsätze und Regeln, Anzahl der Entitäten. 2. Violations Overview - Die Gesamtzahl der Violations und ihre Unterteilung in Critical, High, Medium, Low und Info. Die Anzahl der Fehler entspricht der Anzahl der Compliance Rules, die nicht erfolgreich ausgeführt wurden. 3. Entity Rule Set Score Distribution 4. Violations by Entity Type - zeigt die Anzahl der Critical, High, Medium usw. Violations nach Entitätstyp an. Abb. 14: Ergebnis Assessmentlauf in der Weboberfläche   Ein Assessment Report in Form einer HTML-Datei wird ebenfalls erstellt.   Abb. 15: Ergebnis Assessmentlauf als Report Der HTML-Bericht enthält eine Zusammenfassung mit allen Regelergebnissen (rule results) und den entsprechenden Details für jede der bestandenen/nicht bestandenen Regel.   Abb. 16: Ergebnis Assessmentlauf Regelauswertung Informationen zum Beispiel Assessment aus der ersten Regel der obigen Liste:   Abb. 17: Ergebnis Assessmentlauf Detailinformationen zu einer Regel Die Assessmentergebnisse helfen Compliance-Administratoren, Compliance Violations zu priorisieren und einen Remediation Plan (Behebung/Korrektur/Verwerfung der Verletzungen) zu erstellen.   Abb. 18: Ergebnis Assessmentlauf Violations   Abb. 19: Ergebnis Assessmentlauf Detail einer Violation PLANUNG DER REMEDIATION Während der Planung der Remediation wird bestimmt wie mit Compliance Violations verfahren wird. Violations können verworfen werden (z.B. nicht relevant), ein automatisiertes Skript zur Behebung erstellt und ausgeführt werden oder die Violations manuell bearbeitet werden. Mit der erneuten Ausführung des Assessment Template kann die erfolgreiche Remediation überprüft werden. Dieser Service nutzt Alerts, Remediations und Reports. Über Alert Rules können Benutzer bestimmt werden, die die Benachrichtigungen auf Basis gewünschten Bedingungen erhalten.   Abb. 20: Definition eines Alarms   Abb. 21: Übersicht Alarme Bei der Konfiguration der Alert Rule können Remediation Actions hinzugefügt werden. Diese Remediation Actions werden automatisch durchgeführt, wenn ein Alert ausgelöst wird oder sich der Schweregrad verschlechtert. Die Remediation Actions können aus Workflows bestehen, die im Oracle Orchestration Cloud Service erstellt wurden. Sie müssen nur den veröffentlichten Workflow für die Remediation Actions hinzufügen und die Auto Remedation wird durchgeführt.   FAZIT Mit dem Configuration und Compliance Service können einfach und schnell Umgebungen gegen standardisierte und eigene Regelwerke getestet werden. Damit können die Instanzen, unabhängig von Ihrem Installationsort, auf ihre Konformität bezüglich der Unternehmensvorgaben überprüft werden. Optional können bei entdeckten Abweichungen neben Alarmen auch Aktionen eingeleitet werden die die Konformität wieder herstellen, z.B. Verschlüsselung in einer Datenbank.  Manche Regularien, wie die im Kreditkartenumfeld, fordern die fortwährende Überwachung der Vorgaben. Dies kann durch Konfiguration der entsprechenden Schedules erreicht werden.  Da die Ergebnisse entsprechend verdichtet präsentiert werden, ist eine Auswertemöglichkeit auch für Nicht-Techniker möglich.  Ähnliche Werkzeuge zur IT-Compliance gibt es auch stand-alone. Der Vorzug bei der Lösung über die Management Cloud ist dass neben der hier dargestellten Funktionalität auch weitere Funktionen wie das Security Monitoring mitkommen.        

Dieser Blog wurde von der Gast Autorin Amalia Darie, Oracle erstellt. Es handelt sich um eine Testanleitung mit dem Configuration und Compliance Cloud Service um eine IT-Compliance mit einer...

Core Tec & Cloud Technologies Deutschland

Deployment eines Oracle NoSQL DB Clusters auf Oracle Cloud Infrastructure VM Shapes

Einleitung Horizontal und elastisch skalierende, verteilte Datenbanken, die flexible Datenmodelle unterstützen, sind immer dann im Fokus, wenn es gilt, beliebige und dynamische Datenströme effizient zu speichern, zu verarbeiten und einfach wieder auf diese zuzugreifen. NoSQL Datenbanken sind genau für solche Anwendungsfälle bestimmt. Die sehr kostengünstigen Oracle Cloud Infrastructure (kurz OCI) Ressourcen wie Compute, Storage und Network lassen sich hervorragend dafür nutzen, um ein Oracle NoSQL Datenbank Cluster aufzusetzen und zu betreiben. Dieser Artikel beschreibt, wie Sie einfach und schnell ein Oracle NoSQL DB Cluster mit 3 Knoten deployen und darauf zugreifen. Er beschreibt nicht, wie Sie dann eine Anwendung bauen mit der Oracle NoSQL DB als darunterliegendem Datastore. Dieses Wissen ist in anderen Blog Posts wie diesem beschrieben oder auch als Sample Code u.a. auf Github veröffentlicht. Basis für das Deployment des Oracle NoSQL DB Clusters sind virtualisierte (VM) Compute Shapes. An diese werden jeweils Block Volumes als zusätzlicher Storage gehängt, welche die Daten aufnehmen sollen. Grundlage für die Kommunikation der Knoten untereinander ist ein virtuelles Cloud Netzwerk, VCN genannt. Alle Schritte werden einzeln ausgeführt und kurz beschrieben. Der ganze Vorgang läßt sich natürlich auch mittels Terraform, Ansible oder generell Skript-basiert automatisieren. Alternativ zu den Ausführungen hier gibt es auch ein White Paper (Version vom April 2018) in englischer Sprache, bei welcher für das Deployment die teureren, mit mehr CPUs und Hauptspeicher ausgestatteten OCI Baremetal Shapes verwendet werden. Deren Nutzung ist insbesondere dann zu empfehlen, wenn dedizierte Hard- und Netzwerkressourcen für sehr hohe und höchste Ansprüche sowohl an Performanz als auch Kontrolle zum Einsatz kommen sollen, egal ob Sie ein Oracle NoSQL DB Cluster oder eine andere geclusterte NoSQL Datenbank darauf installieren. Für den Einstieg ins Thema, für nicht geschäftskritische Anwendungen oder auch für die Evaluierung auf eigenen Ressourcen sind VM Shapes perfekt geeignet. Diese können Ihnen ausgestattet ab 1 CPU (genauer gesagt OCPU) und 8 GB Arbeitsspeicher bereitgestellt werden. Bevor es zum Deployment geht, sei hier noch ein kurzen Überblick zur Datenbank selbst gegeben. Die Oracle NoSQL DB ist ein einfach aufzusetzender, hochverfügbarer und hochperformanter Key-Value-Store ( KVStore), der mit sehr wenig Administration auskommt. Dem KVStore zugrunde liegt die Berkeley DB Java Edition, eine weit-verbreiteter embedded KVStore, welcher um Funktionen wie Clustering, Sharding und Replikation erweitert wurde. Die Oracle NoSQL DB steht in 3 Editionen zur Verfügung. Die Unterschiede zwischen den einzelnen Editionen sind in diesem FAQ beschrieben. Wesentliche Punkte sollen hier kurz angeführt werden: Enterprise Edition (EE) Diese Edition enthält alle Features der Basic Edition und Community Edition plus weitere Features, die wesentlich sind für die Integration mit anderen Oracle sowie Third-Party-Software-Komponenten wie Oracle Enterprise Manager, Oracle Coherence, Oracle Big Data Spatial and Graph, Elasticsearch oder Kerberos. Sie können diese Edition 30 Tage kostenfrei evaluieren im Rahmen der Oracle Technology Network (OTN) Lizenzbestimmungen. Basic Edition (BE) Diese Edition kann ohne zusätzliche Lizenzkosten genutzt werden, wenn gültige Lizenzen für die Oracle Datenbank Enterprise Edition vorhanden sind. Die Basic Edition kann derzeit nur über edelivery.oracle.com heruntergeladen werden. Der Versionsstand ist nicht gleich dem der Enterprise Edition sondern "hängt" typischerweise um ca. 1 Jahr zurück. Community Edition (CE) Die Edition steht als freie Software unter der Apache 2.0 Lizenz zur Verfügung. Die Software kann über die Oracle Technology Seiten heruntergeladen werden. Auch bei dieser Edition gibt es einen zeitlichen Versatz zur Versionierung der Enterprise Edition, analog der Aussage für die Basic Edition. Ausführliche Informationen zur Oracle NoSQL DB gibt es auf den entsprechenden Oracle Technology Network Seiten.   Überblick der auszuführenden Schritte Aufsetzen des OCI Ressourcen Anlegen von Nutzerberechtigungen auf Betriebssystem-Ebene Download und Installation/Update des Oracle Java Development Kit (JDK) auf allen DB Knoten Download und Installation der Oracle NoSQL DB Software auf allen DB Knoten Einrichten des Oracle NoSQL DB Clusters Überprüfen des Zugriffs mittels Admin REST API für die Oracle NoSQL DB   Architektur des Oracle NoSQL DB Clusters Ein Oracle NoSQL DB Cluster besteht aus sogenannten Storage Nodes. Das ist nichts anderes als CPU, Hauptspeicher und Plattenspeicher. In der verwendeten OCI Umgebung werden dafür Compute Instances mit zusätzlich je 3 angehängten Block Volumes eingesetzt. Die 3 Clusterknoten, oder Storage Nodes, sind dafür da, Daten horizontal verteilt parallel schreiben und auch wieder auslesen zu können. Jeder Storage Node erhält beim Schreiben ein unterschiedliches Set an Daten. Die Verteilung erfolgt über eine Hash-Funktion. Je mehr Storage Nodes das Cluster enthält, umso mehr kann gleichzeitig parallel verteilt geschrieben werden. Um Ausfallsicherheit zu erzeugen, werden die Daten nach dem initialen Schreiben (auf den sogenannten Masterknoten) zusätzlich auf weitere Knoten repliziert. Der empfohlene minimale Replikationsfaktor liegt bei 3. Das bedeutet: 1x Schreiben auf den Masterknoten Von dort Replikation auf 2 weitere (Slave) Knoten   Abb. 1: Schematische Darstellung eines Oracle NoSQL DB Clusters   Fällt jetzt ein Knoten aus, ist sichergestellt, daß sich jeder Datensatz auf noch mindestens 2 weiteren Knoten befindet. Diese wählen dann unter sich ggf. einen neuen Master, um die nachfolgenden Schreibprozesse sicherzustellen. Die nebenstehende Abbildung verdeutlicht die Architektur. Sie stellt ein 3x3 Cluster dar. Das bedeutet, 3 Shards werden auf 3 Storage Nodes verteilt. Der Master und dessen 2 Replikas für jedes Shard (zusammengefaßt ergeben sie eine Replikationsgruppe) liegen jeweils auf unterschiedlichen Storage Nodes. Physikalisch werden in meiner Umgebung die Daten auf die den Compute Instanzen angehängten Block Volumes verteilt. Ein Block Volume erhält jeweils die Master-Daten. 2 weitere Block Volumes auf je einer anderen Compute Instanz nehmen die Replikate auf.   Deployment des Oracle NoSQL DB Clusters Es gibt in der OCI Documentation ausführliche Beschreibungen, wie die jeweiligen Ressourcen eingerichtet werden. Daher ist die Konzentration hier auf die Punkte, die wesentlich sind in Bezug auf das Deployment der Oracle NoSQL DB. Einrichten der OCI Ressourcen Netzwerk Ein VCN inklusive Subnetze, Internet Gateway und Route Tables, kann am einfachsten  in einem Schritt angelegt werden. Dazu wird im "Create Virtual Cloud Network" Dialog die Option "CREATE VIRTUAL CLOUD NETWORK PLUS RELATED RESOURCES" ausgewählt. Die verwendeten Eingabewerte für das VCN sind folgende: NAME: Oracle_NoSQL_VCN CIDR Block: 10.0.0.0/16 Im Ergebnis wird das VCN mit 3 Subnetzen angelegt, verteilt auf die 3 Oracle Cloud Rechenzentren (im OCI Kontext Availability Domains genannt) in Frankfurt a.M.   Abb. 2: In OCI angelegte Subnetze   Zusätzlich werden automatisch Zugriffsrechte über eine sogenannte Security List vergeben. Diese Security List muß noch angepaßt werden, um die Kommunikation der Storage Nodes untereinander und auch der Anwendung mit dem KVStore zu ermöglichen. Dafür werden zusätzliche Ports freigeschaltet. Für den aufzusetzenden KVStore ist das der Port-Bereich 5000 bis 5050. Die nachfolgende Abbildung zeigt die Zugriffsregeln. Darin sind die ersten 3 sogenannten Ingress Rules Standard-Einstellungen. Die vierte Ingress Rule wurde hinzugefügt: Source CIDR: 10.0.0.0/16 IP Protocol: TCP Source Port Range: All Destination Port Range: 5000-5050   Abb. 3: Security Lists in OCI   Storage Als nächstes werden insgesamt 9 Block Volumes angelegt, auf denen die Daten gespeichert werden sollen. Diese Volumes werden auf alle 3 Availability Domains verteilt, wie jeweils am Kürzel "AD" im Namen zu erkennen ist. Die Eingabewerte pro Volume sind ein Name, die Auswahl der Availability Domain, die Größe in GB sowie die Angabe einer Backup Policy. Eine Backup Policy wurde in dieser Umgebung nicht spezifiziert. Es werden also keine automatischen Backups angelegt.   Abb. 4: In OCI verwendete Block Volumes   Compute Instanzen Nun werden noch 3 Compute Instances angelegt. Dabei sind folgende Eingabewerte anzugegeben bzw. auszuwählen: Name Availability Domain Image Source Instance Type: Virtual Machine Instance Shape Configure Boot Volume Add SSH key Virtual Cloud Network Compartment Virtual Cloud Network Subnet Compartment Subnet Für mehr Infos zu den einzelnen Parametern und insbesondere auch zum Zuweisen des Public SSH Key schauen Sie am besten in die Dokumentation oder in eines der vorhandenen Tutorials. Der passende Private SSH Key (beides zusammen, Public und Private SSH Key, können Sie z.B. mit Hilfe von PuTTYgen anlegen) wird dann lokal für die SSH Client Software benötigt.   Abb. 5: In OCI verwendete Compute Instanzen   Jeder der Compute Instanzen werden über "Attach Block Volumes" 3 Volumes zugeordnet.   Abb. 6: Compute Instanz und zugeordnete Block Volumes   Zusätzlich sind für das Attachment noch ein paar wenige Kommandos (iSCSI Commands) auf Betriebssystem-Ebene auszuführen. Diese können per Copy & Paste aus den Compute Instance Details der OCI Konsole geholt werden.   Abb. 7: Zusätzliche Kommandos und Informationen für das Anhängen der Block Volumes   Dafür gehen Sie zunächst mit einem SSH Client (z.B. PuTTY, MobaXTerm) und dem Cloud Nutzer "opc" auf die jeweilige Compute Instanz. Vergessen Sie dabei nicht, in den Verbindungsdetails den Private SSH Key anzugeben und ggf. auch einen Proxy einzutragen. Bei PuTTY sieht ersteres wie in der nachfolgenden Abbildung aus:   Abb. 8: PuTTY: Mit lokalem SSH Client auf die Compute Instanzen zugreifen   Anlegen von Nutzerberechtigungen und Mounten der Volumes Auf Betriebssystem-Ebene sind nun noch ein paar administrative Arbeiten zu erledigen. Im wesentlichen geht es darum, einen spezifischen Nutzer anzulegen, die Volumes zu mounten und die Compute Instanzen in die jeweilige /etc/hosts aufzunehmen. Passen Sie die Skriptbeispiele entsprechend Ihrer Cloud Instanzen an. Gruppe und Nutzer anlegen sudo groupadd nosql sudo useradd -m nosql -p <pwd> -g nosql sudo usermod -aG wheel nosql Hinweis: Wenn Sie sich das 1. Mal über den Nutzer "nosql" mit der Compute Instanz verbinden, werden Sie mit der Meldung "Server refused our key" konfrontiert. Dieses Problem kann leicht behoben werden. Das Vorgehen ist in der MyOracleSupport Note mit der Doc ID 2409609.1 beschrieben.  Volumes mounten # Show block storage devices lsblk   # Show all mounted disks mount   # Create directories sudo mkdir -p /disk1 sudo mkdir -p /disk2 sudo mkdir -p /disk3   # Create filesystems sudo mkfs.ext4 -F /dev/sdb sudo mkfs.ext4 -F /dev/sdc sudo mkfs.ext4 -F /dev/sdd   # Mount filesystems sudo mount /dev/sdb /disk1 -o _netdev sudo mount /dev/sdc /disk2 -o _netdev sudo mount /dev/sdd /disk3 -o _netdev   # Add to fstab /dev/sdb                /disk1                  ext4    defaults,_netdev,nofail  0 0 /dev/sdc                /disk2                  ext4    defaults,_netdev,nofail  0 0 /dev/sdd                /disk3                  ext4    defaults,_netdev,nofail  0 0   # Add hosts to /etc/hosts 10.0.0.2 oracle-nosql-db-ad1-0.sub01234567890.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad1-0 10.0.1.2 oracle-nosql-db-ad2-0.sub02345678901.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad2-0 10.0.2.2 oracle-nosql-db-ad3-0.sub03456789012.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad3-0   # Add additional required directories sudo mkdir -p /disk1/ondb/data sudo mkdir -p /disk2/ondb/data sudo mkdir -p /disk3/ondb/data sudo mkdir -p /disk1/ondb/rnlog sudo mkdir -p /disk2/ondb/rnlog sudo mkdir -p /disk3/ondb/rnlog sudo mkdir -p ~/ondb/admin Download und Installation des Oracle Java Development Kit (JDK) Die aktuelle Version der Oracle NoSQL DB (18.3.11) erfordert Java SE 8 oder höher. Laden Sie sich das entsprechende JDK herunter und kopieren Sie dieses auf alle 3 Compute Instanzen. Legen Sie sich ggf. für alle Download Dateien ein entsprechendes Verzeichnis an, z.B. /home/nosql/Downloads. Anschließend installieren Sie das JDK auf allen 3 Compute Instanzen. Falls noch nicht gesetzt, definieren Sie dauerhaft die Umgebungsvariable JAVA_HOME. # Check Java version java -version cd ~/Downloads   # Install JDK sudo rpm -ivh jdk-8u201_linux_x64.rpm   # Set environment variable echo "export JAVA_HOME=/usr/java/latest" >> ~/.bashrc echo "export PATH=$JAVA_HOME/bin:$PATH" >> ~/.bashrc Download, Installation und Deployment der Oracle NoSQL DB Analog können Sie jetzt für die Installation der Oracle NoSQL DB vorgehen. Wählen Sie eine der Download Dateien aus, entweder die Community Edition oder die Enterprise Edition. Sie erinnern sich: Die Community Edition ist eine freie Software. Aber auch die Enterprise Edition können Sie im Rahmen der Oracle Technology Network (OTN) Lizenzbestimmungen für 30 Tage kostenfrei evaluieren. Ein großer Vorteil der Enterprise Edition ist, daß sie immer den neuesten Releasestand wiedergibt. Zusätzlich sollten Sie auch gleich die Oracle NoSQL DB Examples herunterladen und ebenfalls installieren. Diese enthalten u.a. Beispielcode. Ausführliche Anleitungen finden Sie in der Oracle NoSQL DB Dokumentation. su - nosql   # Unzip install files to nosql user home cd ~ gunzip ~/Downloads/kv-ee-18.3.11.tar.gz gunzip ~/Downloads/kv-examples-18.3.11.tar.gz tar -xvzf kv-ee-18.3.11.tar tar -xvzf kv-examples-18.3.11.tar ls -l kv-18.3.11   # Create KV root directory mkdir kvroot   # Set environment variables echo "export KVHOME=~/kv-18.3.11" >> ~/.bashrc echo "export KVROOT=~/kvroot" >> ~/.bashrc echo "export CLASSPATH=$KVHOME/lib/*:$CLASSPATH" >> ~/.bashrc source ~/.bashrc echo $KVHOME echo $KVROOT ls -l   # Check installation java -Xmx64m -Xms64m -jar $KVHOME/lib/kvclient.jar java -jar $KVHOME/lib/kvstore.jar ping -host localhost -port 5000 Für das Deployment der Oracle NoSQL DB, also das Aufsetzen des Clusters, braucht es 3 Schritte: Bootstrapping Start des Storage Node Agent Deployen der Topologie Auch diese 3 Schritte werden wieder auf allen Storage Nodes ausgeführt. Für das Bootstrapping müssen zunächst die wichtigsten Parameter konfiguriert werden. Ausführliche Infos über die Parameter und deren Anwendung finden sich in der Dokumentation. Die Bootstrapping Datei makebootconfig.sh für die Umgebung sieht folgendermaßen aus: #!/bin/bash   # Login as user nosql # Use the makebootconfig utility to generate the configuration. We do this for each storage node # -root the KVROOT directory # -host node hostname or IP address # -port specifies the registry port used by the Storage Node Agent # -admin specifies the port used by Administration Service to listen for HTTP connections # -harange specifies the range port used by the replication nodes and Administration services # -capacity specifies number of a Replication Nodes supported by Storage Node # -num_cpus used when multiple Replication Nodes are configured on a Storage Node. If the value is 0, the system will attempt to query the Storage Node to determine the number of processors on the machine. # -memory_mb total memory available for the cache and heap sizes. If the value is 0, the store will attempt to determine the amount of memory on the machine, but that value is only available when the JVM used is the Oracle Hotspot JVM. # -store-security specifies if security will be used or not. In this example no security is used.   ########### Bootstrap Storage Node 1 ########## java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \     -root $KVROOT \     -host 10.0.0.4 \     -port 5000 \     -admin-web-port 5010 \     -servicerange 5015,5025 \     -harange 5030,5050 \     -capacity 3 \     -admindir /home/nosql/ondb/admin \     -admindirsize 50_GB \     -store-security none \     -memory_mb 6000 \     -storagedir /disk1/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk2/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk3/ondb/data \     -storagedirsize 250_GB \     -rnlogdir /disk1/ondb/rnlog \     -rnlogdir /disk2/ondb/rnlog \     -rnlogdir /disk3/ondb/rnlog echo " Done bootstrapping storage-node 1" ################################################   ########### Bootstrap Storage Node 2 ########### java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \     -root $KVROOT \     -host 10.0.1.3 \     -port 5000 \     -admin-web-port 5010 \     -servicerange 5015,5025 \     -harange 5030,5050 \     -capacity 3 \     -admindir /home/nosql/ondb/rnlog \     -admindirsize 50_GB \     -store-security none \     -memory_mb 6000 \     -storagedir /disk1/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk2/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk3/ondb/data \     -storagedirsize 250_GB \     -rnlogdir /disk1/ondb/rnlog \     -rnlogdir /disk2/ondb/rnlog \     -rnlogdir /disk3/ondb/rnlog echo " Done bootstrapping storage-node 2" ################################################   ############ Bootstrap Storage Node 3 ########## java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \     -root $KVROOT \     -host 10.0.2.3 \     -port 5000 \     -admin-web-port 5010 \     -servicerange 5015,5025 \     -harange 5030,5050 \     -capacity 3 \     -admindir /home/nosql/ondb/admin \     -admindirsize 50_GB \     -store-security none \     -memory_mb 6000 \     -storagedir /disk1/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk2/ondb/data \     -storagedirsize 250_GB \     -storagedir /disk3/ondb/data \     -storagedirsize 250_GB \     -rnlogdir /disk1/ondb/rnlog \     -rnlogdir /disk2/ondb/rnlog \     -rnlogdir /disk3/ondb/rnlog echo " Done bootstrapping storage-node 3" ################################################ Nun wird das Bootstrapping ausgeführt. ./makebootonfig.sh Für den 2. Schritt, das Starten des Storage Node Agent (SNA), wird das Skript startSNA.sh ausgeführt. Dessen Inhalt sieht folgendermaßen aus: #!/bin/bash   export MALLOC_ARENA_MAX=1   ##### Start SNA on each Storage Node ########## java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar start -root $KVROOT & echo " Done starting SNA" Starten des SNA ./startSNA.sh Der 3. und letzte Schritt ist das Deployment der Clustertopologie, also in dieser Umgebung ein 3x3 Cluster. Zuerst sehen Sie wieder das zugehörige Skript (3x3.kvs), jetzt mit den spezifischen Admin Befehlen für die Oracle NoSQL DB: ### Begin Script ########################################### configure -name kvstore plan deploy-zone -name "Frankfurt" -rf 3 -wait   ####### Deploy First Storage Node  ######################### plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.0.4 plan deploy-admin -sn sn1 -wait   ###### Deploy Second Storage Node ########################## plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.1.3 plan deploy-admin -sn sn2 -wait   ###### Deploy Third Storage Node ########################### plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.2.3 plan deploy-admin -sn sn3 -wait   ####### Create Storage Pool ################################ pool create -name AllStorageNodes pool join -name AllStorageNodes -sn sn1 pool join -name AllStorageNodes -sn sn2 pool join -name AllStorageNodes -sn sn3   ######## Create topology, preview it and then deploy it ##### topology create -name 3x3 -pool AllStorageNodes -partitions 120 topology preview -name 3x3 plan deploy-topology -name 3x3 -wait ### End Script ############################################# Schließlich fehlt noch das Ausführen dieses Skripts. Hierbei ist zu beachten, daß die (interne) IP Adresse, welche auf den Parameter host folgt, pro Storage Node angepaßt werden muß: java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host 10.0.0.4 load -file 3x3.kvs Ob das Deployment erfolgreich war, sehen Sie direkt beim Ausführen der 3 Schritte. Zusätzlich kann aber gern noch mal ein ping auf das Cluster ausgeführt werden. java -jar $KVHOME/lib/kvstore.jar ping -host localhost -port 5000   Abb. 9: Ping auf den Oracle NoSQL DB Cluster   Detaillierter reinschauen können Sie auch mit einem Admin Interface. Es gibt sowohl ein Kommandozeilen-basiertes als auch ein RESTful Web Service. Das REST Interface wurde automatisch nach dem Deployment gestart, weil in der makebootconfig Datei der Parameter admin-web-port konfiguriert wurde. Ein REST Call zum Anzeigen der Clustertopologie und der entsprechende Response sehen dann so aus: curl -i -X POST "http://10.0.0.4:5010/V0/nosql/admin/topology" -d '{"command":"show"}'   Abb. 10: REST Call auf das Oracle NoSQL DB Admin Interface   Fazit Horizontal skalierende, verteilte Datenbanken sind immer dann im Fokus, wenn es gilt, beliebige Datenströme in Echtzeit oder Echtzeit-nah aufnehmen zu können und mit einfachen Zugriffen, die Daten auch wieder auszulesen. Die Oracle NoSQL DB ist eine solche Datenbank. Für deren Nutzung können Sie sich entscheiden, einen Cluster mit eigenen Hardware Ressourcen aufzubauen. Als sehr kostengünstige und flexible Alternative bietet sich das Deployment auf der Oracle Cloud Instrastructure an. Alle notwendigen Ressourcen werden hierüber innerhalb weniger Minuten und mit wenig Aufwand bereitgestellt. Sie haben die Kontrolle, wofür Sie welche Ressourcen einsetzen. Allerdings obliegt Ihnen auch die Administration, inklusive Upgrades und Patching. Möchten Sie sich nur noch auf das Entwickeln von Anwendungen mit der Oracle NoSQL DB als darunterliegendem Datenmanagementsystem konzentrieren, dann haben Sie zusätzlich die Möglichkeit der Nutzung des Oracle NoSQL DB Cloud Service. Dieser Service wird nicht in Form von Shapes provisioniert sondern kommt als Anwendung daher. Auf diese Anwendung können Sie mittels spezifischer Rechte zugreifen und somit eigene Anwendungen erstellen. Der Service ist also konzipiert für AnwendungsentwicklerInnen. Er wird Gegenstand eines zukünftigen Artikels sein. Also schauen Sie gern bei Gelegenheit wieder rein.

Einleitung Horizontal und elastisch skalierende, verteilte Datenbanken, die flexible Datenmodelle unterstützen, sind immer dann im Fokus, wenn es gilt, beliebige und dynamische Datenströme effizient...

IaaSundPaaS

Funktionsweise der OCI Remote Console

Wenn man in der Oracle Cloud Infrastructure Services erzeugt, auf denen man Betriebssystem-Zugriff hat, verbindet man sich primär mittels SSH-Protokoll. Ist ein Zugriff nicht möglich, ist es normalerweise nicht einfach, die Ursache dafür herauszufinden. Gründe kann es viele geben: die Maschine fährt nicht ordentlich hoch, es gibt Probleme mit den SSH-Key, die Netzwerkverbindung ist nicht stabil etc.  Eine mögliche Lösung ist die Verwendung der "Remote-Console". Diese Funktion ermöglicht es, sich "direkt" mit der Maschine zu verbinden, d. h. man sieht den vollständigen Boot-Vorgang und alle durchgeführten Schritte. Die Remote-Console bietet eine vergleichbare Funktionalität, als hätte man direkten Zugriff auf den Rechner. Aufgaben, die man mit der Remote-Console durchführen kann, sind zum Beispiel:  Hochfahren des Rechners in den Maintenance Mode, zum Debugging von fehlerhaften Instanzen Änderung der Systemkonfiguration Hinzufügen oder Ändern des SSH-Keys für den Standard Benutzer OPC Anmelden und Administration von grafischen Betriebssystemen, wie zum Beispiel Windows Im nachfolgenden Artikel werden die Konfiguration und Nutzung der Remote-Console erklärt und hilfreiche Tipps & Tricks aufgezeigt.  Benutzung der Remote-Console Es gibt zwei Möglichkeiten die Remote-Console zu verwenden, auf API-Ebene oder über die OCI-Web-Console. Mit der API können die  Konsolenausgaben ermittelt werden, es handelt sich um einen Read-Only-Vorgang. Die API-Ausgabe kann zum Beispiel in eine Datei abgespeichert werden, um sie zu einem späteren Zeitpunkt zu analysieren.  Bild 1: Kommandozeilenausgabe des Konsolen-Output beim Herunterfahren der Compute-Instanz Wenn man aktiv etwas mit der Konsole ändern möchte, kommt man nicht um die OCI-Web-Konsole herum. Die OCI-Web-Konsole ist in diesem Fall das Werkzeug, um die Verbindung vom lokalen Client zur Remote-Console einzurichten. Anschließend kann man sich entweder grafisch per VNC (Virtual Network Computing) oder mittels Terminal per SSH mit der Remote-Console verbinden. Beide Verbindungsarten haben Ihre Vor- und Nachteile, auf die in diesem Artikel eingegangen wird. Das Einrichten erfolgt auf OCI-Web-Konsole der jeweiligen Instanz. Ruft man die Detailseite auf, kann man auf der unteren linken Seite den Punkt "Console Connection" anklicken. Es kann nur eine Verbindung pro Instanz erzeugt werden. Nötig ist ein OpenSSH-Key-Paar, das man entweder für die Verbindung explizit erzeugt, oder man verwendet das Standardschlüsselpaar, das bei linuxbasierten Betriebssystemen im Benutzerverzeichnis liegt (zum Beispiel id_rsa.pub).  Bild 2: Erzeugen der Konsolenverbindung   Bild 3: Eingabe des OpenSSH-Public-Keys Wenn man sich gegen die Remote-Console verbindet, kann man dies mit dem VNC- oder SSH-Protokoll tun, ich persönlich empfehle für die meisten Fälle die SSH-Verbindung. Wenn man sich per VNC verbindet, hat man das maschinenspezifische Default-Key-Mapping der Tastatur. Das führt dazu, dass beim Editieren von Konfigurationsdateien die Hauptzeit damit verbracht wird, die korrekten Sonderzeichen durch die "Try & Error"-Methode zu finden. Die VNC-Methode hat ihre Anwendungsfälle üblicherweise bei grafischen Betriebssystemen. Wenn es darum geht, auf einem Linux-Server etwas zu ändern, ist die Nutzung der SSH-Variante üblicherweise von Vorteil. Aufbauen einer VNC/SSH-Verbindung Um diese Verbindungsart zu initiieren, klickt man auf die Detailinformationen der Console-Connection der gewünschten Instanz und wählt "Connect with VNC". Anschließend sucht man sich das richtige Betriebssystem auf der Client-Seite aus und kopiert sich die Verbindungsbefehlszeile. Vorsicht!!! Der Befehl geht davon aus, dass man den Standard-OpenSSH-Key verwendet hat, d. h. wenn man einen anderen Schlüssel verwendet, muss man diesen Befehl um den Standort des Private-Key-Files erweitern. Für Linux-basierte Betriebssysteme ist das: statt: ssh -o ProxyCommand='ssh -W %h:%p -p 443 ... Muss man den Ort des SSH-Private-Key-Files angeben ssh -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443 ... Für Windows-Betriebssysteme sind noch ein paar Sonderkonfiguration durchzuführen, diese sind hier erklärt https://docs.cloud.oracle.com/iaas/Content/Compute/References/serialconsole.htm Anschließend setzt man den Befehl in einem Terminal-/CMD-Fenster ab und kann mit einem VNC Viewer (zum Beispiel VNC Viewer) über localhost Port 5900 die Konsole anzeigen. Bild 4: VNC Console mit Windows-Server-Startbildschirm Diese Methode ist bei grafischen Betriebssystemen üblich. Wenn es darum geht, auf einem Linux-Server etwas zu ändern ist die Nutzung der SSH-Variante von Vorteil. Zum Öffnen einer SSH-Session geht man gleich vor, wie beim Aufbau einer VNC-Verbindung, nur dass man anstatt der VNC- nun die SSH-Befehlszeile wählt. Auch hier ist zu beachten, dass man den die SSH-Befehlszeile bei Nutzung eines eigenen OpenSSH-Key-Paares um die Lokation des Private-Key-Files erweitern muss! Den Befehl gibt man anschließend in ein Terminal-/CMD-Fenster ein und ist nun direkt mit der Remote-Console verbunden. Im Terminal-/CMD-Fenster ist es nicht immer ersichtlich, dass die Verbindung erfolgreich war, in diesem Fall reicht es, noch einmal Return zu drücken. Sollte dies nicht den gewünschten Erfolg bringen, sollten Sie die Service-Instanz rebooten, der Reboot sollte im SSH-Fenster zu sehen sein. An dieser Stelle noch ein Hinweis: Wenn es bereits eine bestehende Verbindung gibt, vielleicht aus vorherigen Versuchen oder durch einen anderen Benutzer, kommt es zu einer Fehlermeldung, da sich die Verbindung nicht aufbauen kann. In diesem Fall hilft es, die bestehende Verbindung zu beenden oder einen Timeout abzuwarten, bis die Verbindung wieder verfügbar ist.  Ändern des SSH Keys mit Remote Konsole Jetzt, wo wir eine Verbindung zur Server-Instanz haben, können wir verschiedene Arbeiten durchführen. Eine der am häufigsten durchgeführten Aufgaben ist das Ändern des SSH-Key, wenn dieser zum Beispiel verloren gegangen ist und man dadurch keine Verbindung mehr zu seinem Server erhält. Für diesen Fall verbindet man sich wie oben beschrieben mittels SSH an die Remote-Console und führt folgende Schritte durch: Der Neustart wird zum Beispiel über die Web-Konsole initiiert, während des Neustarts drückt man die Oben bzw. Unten-Taste, um in das GRUB-Boot-Menü zu gelangen.  Bild 5: GRUB-Boot-Menü für Oracle Linux Im nächsten Schritt muss die Startkonfiguration geändert werden, damit man in die Linux-Bash-Shell kommt. Dies benötigt man, um den SSH-Key anpassen zu können. Dazu wählt man im GRUB-Menü die aktuelle Instanz aus, in diesem Fall Oracle Linux mit dem aktuellen Kernel und drückt die Taste "e" für Editieren. Anschließend navigiert man mit den Pfeiltasten nach unten bis zur Zeile: "linuxefi", dort fügt man am ENDE der Zeile folgendes ein:  init=/bin/bash  und drückt die Tastenkombination Ctrl-X, die einen Neustart des Servers veranlasst. Hinweis: Nicht die ESC-Taste drücken, die bewirkt, dass auf das GRUB-Menü zurückgegangen wird, ohne die Änderungen zu übernehmen! Bild 6: Änderung des Startmenüs Nach dem Neustart landet man in der Bash-Eingabeaufforderung und muss eine Reihe von Kommandos eingeben, bevor man den SSH-Key bearbeiten darf. /usr/sbin/load_policy -i Dieses Kommando lädt die SELinux-Richtlinien, um die Schlüsseldatei ändern zu dürfen. /bin/mount -o remount, rw / Re-Mount der Root-Partition mit Lese-und Schreibrechten Wechseln in das .shh-Verzeichnis des OPC-Benutzers und Ändern des Inhaltes der authorized_keys Datei cd ~opc/.ssh mv authorized_keys authorized_keys.old echo '<contents of .pub key file>' >> authorized_keys Zur Sicherheit benennt man die Orginaldatei um und speichert den neuen Inhalt des zu verwendenden Public-Keys in die Datei authorized_keys. Man kann das natürlich auch mit einem Editor, wie zum Beispiel VI, machen. Wichtig an dieser Stelle ist, dass es OpenSSH-Format ist und der Inhalt der SSH-Public-Key-Datei ohne Änderungen in die Datei kopiert wird. Tipp: Damit die Verbindung mit dem neuen OpenSSH-Private-Key funktioniert, müssen zwei Dinge sichergestellt sein. Erstens: Die Lese-/Schreibrechte der authorized_keys-Datei müssen korrekt sein (Datei-Owner Read/Write), sollte dies nicht der Fall sein, kann man mit folgendem Befehl die Rechte korrekt setzen: chmod 600 authorized_keys Da man als Root angemeldet ist, wird die neue Authorized_keys-Datei, also Benutzer und Gruppe Root, angelegt, da man sich mit dem Benutzer OPC anmeldet, muss der Besitzer geändert werden, dies wird durch den folgenden Befehl gewährleistet: chown opc:opc authorized_keys* Im letzten Schritt startet man die Instanz neu: /usr/sbin/reboot -f Nun kann man sich mit seinem neuen SSH-Private-Key an die Instanz anmelden. Fazit Die Remote-Console dient dazu, im Falle eines schwerwiegenden Fehlers Zugriff auf die "lokale" Konsole zu haben, sie ist nicht dafür ausgelegt, dauerhaft auf der Instanz zu arbeiten. Daher empfehle ich die Console-Connection immer nur temporär und bei Bedarf einzurichten und bei Nichtbenutzung zu löschen. Die Console-Connection kann ein Sicherheitsrisiko darstellen, wenn ein Unbefugter Zugriff bekommt. Die Remote-Console ist ein sehr wichtiges Tool, um im Fall der Fälle eine Verbindung auf die betroffene Instanz zu haben. Debugging und Konfigurationsänderungen können mit der Remote-Console schnell und direkt durchgeführt werden.   

Wenn man in der Oracle Cloud Infrastructure Services erzeugt, auf denen man Betriebssystem-Zugriff hat, verbindet man sich primär mittels SSH-Protokoll. Ist ein Zugriff nicht möglich, ist es...

CloudDev

Oracle Kubernetes Engine in der Oracle Cloud Infrastructure

Kubernetes ist ein Open-Source-Container-Orchestrierungs-Tool ursprünglich entwickelt von Google und anschließend gespendet an die Cloud Native Computing Foundation, in der u.a. auch Oracle Mitglied ist. Kubernetes oder abgekürzt K8s wird für die Automatisierung von Bereitstellung, Skalierung und Management von Container-Applikationen verwendet. Die Installation, Setup und Pflege von K8s setzt einen gewissen Aufwand voraus. Grund hierfür ist die Verwendung verschiedener Compute-Knoten, die das K8s-Cluster darstellen. Auf jeden dieser Knoten-Hosts werden von K8s sogenannte Pods bereitgestellt. Ein Pod ist eine Gruppe von ein oder mehreren Container (zum Beispiel Docker-Container), die gemeinsame Ressourcen verwenden, wie u.a Netzwerk und Storage. Ein Pod stellt einen applikationsspezifischen, logischen Host dar, der verschiedene eng verzahnte Applikations-Container enthält. Die Orchestrierung der zu verwendenden Hosts und Zusatzkomponenten, wie zum Beispiel Load Balancer, erfordert einen hohen durchgängigen Automatisierungsgrad. Für diese Anforderungen bietet sich die K8s Installation in einer Cloud-Umgebung an. In dem folgenden Artikel wird die Installation, Konfiguration und Applikations-Bereitstellung eines K8s-Clusters in der Oracle Cloud Infrastructure vorgestellt. Die Bereitstellung erfolgt als "fully managed" Service und ist dank der Cloud spezifischen Automatisierung zügig durchgeführt. Dieser Lab-Guide ist sehr ausführlich, er ist eine "Schritt für Schritt"-Anleitung und ist auch für Themen-Neulinge nachvollziehbar. Dieses Beispiel können Sie in einem Oracle Cloud Infrastructure Tenant nachvollziehen. Sollte Sie noch keinen Tenant/Account besitzen können Sie hier einen 300€ free Trial starten. Wenn Sie bereits einen Tenant/Account besitzen erfolgt die Abrechnung des K8s-Services ausschließlich über die verwendeten Compute/Storage/Netzwerk-Ressoucen es wird keine extra K8s-Service-Gebühr fällig. Die Bereitstellung und Nutzung des Services erfolgt in folgenden Kapiteln: Einloggen in die Service-Konsole Vorbereiten der Cluster Bereitstellung Vorbereiten des Netzwerks Erstellung des Clusters Zugriff auf das Cluster Starten des K8s-Dashboards Bereitstellen einer Cluster-Applikation Fazit Wichtige Links In dem hier gezeigten Beispiel wird ein Cluster mit drei virtualisierten Oracle Cloud Infrastruture Compute Instanzen und zwei Load Balancer-Cloud-Services verwendet. 1. Einloggen in die Service-Konsole (ca. 5 Minute) Um sich auf der Konsole einzuloggen benötigen Sie: Benutzername, Passwort, Tenant-Namen OCI-Url (je nach verwendeter Region) Kompatiblen Browser (IE, Chrome, Firefox) WICHTIG! Für den K8s-Cluster-Service benötigen Sie einen dedizierten OCI-Benutzer, diesen können Sie anlegen bzw.  Kontrollieren, in dem Sie im Seitenleisten-Menü auf den Punkt Identity -> User gehen, der zu verwendende Benutzer muss dort angelegt sein/werden. Bild 1: Dedizierte OCI-Benutzer 2. Vorbeiten der Cluster Bereitstellung (ca. 5 Minuten) Nachdem Sie sich in die Service-Konsole eingeloggt haben müssen Sie den zu verwendenden Benutzer mit ausreichenden Rechten ausstatten. Hintergrund: In der Oracle Cloud Infrastructure gilt das "Erstmal-Alles-Verboten-Prinzip", d.h. jede neue Ressource die Sie anlegen besitzt aus Sicherheitsgründen erst mal keine Rechte, bzw. alle Ports sind gesperrt. Um den K8s die benötigten Rechte zu übertragen Navigieren Sie auf Identity -> Policies im linken Seitenleisten-Menü und erstellen Sie die neue Policy. TIP! Die Policy gilt immer nur für das aktuelle Compartment, deshalb stellen Sie sicher das Sie die Policy im "Root" Compartment erstellen, dann ist Sie für alle darunter liegenden Compartments gültig. Bild 2: Rechtevergabe für die Erstellung eines K8s-Clusters Kleine Exkursion: Ein Compartment ist eine Verwaltungseinheit von Ressourcen in der Oracle Cloud Infrastructure, sie können so bestimmte Ressourcen nur einer bestimmten Gruppe von Benutzern zur Verfügung stellen. Die neue Policy nennen Sie in diesem Beispiel "oke-policy", fügen eine Beschreibung hinzu und setzten unter Policy Versioning den Schalter "Keep Policy Current", anschließend setzten sie das Policy-Statement (Bitte ändern Sie nichts am Policy-Statement ): allow service OKE to manage all-resources in tenancy   Bild 3: Setzten der "oke-policy" Diese Policy benötigen Sie, damit der Kubernetes Service (in diesem Fall steht OKE für Oracle Kubernetes Engine) andere Ressourcen nutzen kann. Zum Beispiel, damit Kubernetes selbständig ein Load Balancer-Service anlegen kann, wenn eine Applikation bereitgestellt wird. Zum Abschluss drücken Sie "Create". 3. Vorbereiten des Netzwerks (ca. 10 Minuten) Um das K8s-Cluster zu Installieren werden eine Reihe von Netzwerkkomponenten benötigt, die manuell angelegt werden müssen. Das manuelle Anlegen ermöglicht eine hohe Flexibilität bezogen auf die gewünschte K8s-Architektur. In unserem Fall verteilen wir das K8s-Cluster auf drei virtuelle Hosts in drei verschiedenen, unabhängigen Verfügbarkeitsdomänen (Availability Domains) innerhalb einer Region. Dafür benötigen wird: Ein Virtuelles Cloud Network (VCN) - Das K8s-Cluster läuft in einem eigenem, abgeschotteten Cloud-Netzwerk. Drei Worker-Node-Subnets - Die Worker-Nodes der K8s-Cluster werden auf drei Hosts verteilt und jeder Hosts hat sein eigenes Sub-Netzwerk in je einer Availability Domain (AD). Zwei Load Balancer-Subnets - Für den hochverfügbaren Zugriff auf das K8s-Cluster werden zwei Load Balancer-Subnetze benötigt. Die Load Balancer werden in der Oracle Container Engine automatisch vom K8s-Cluster erzeugt. Bei den Load Balancern handelt es sich um einen Load Balancer-Service, d.h. es werden keine Software-Load Balancer auf virtuellen Maschinen verwendet, sondern ein "echter" Load Balancer Service. I. Anlegen des Virtual Cloud Networks, Internet Gateways und Routing Tabellen Für das Virtual Cloud Network (VCN) legen wir ein leeres Netzwerk an, d.h. wir bestimmen nur den CIDR-Block und den Namen. Die restliche Konfiguration machen wir manuell. Dafür loggen wir uns in den Oracle Cloud Infrastructure Account ein, und navigieren im linken Seitennavigationsmenü auf den Punkt Networking -> Virtual Cloud Networks Um das VCN zu erstellen wählen wir im ersten Schritt das gewünschte Compartment aus Wählen einen aussagekräftigen Namen wie zum Beispiel "oke-vcn" Dann wählen wir im Bereich Select "Create Virtual Cloud Network Only" für den CIDR Block wählen wir den Bereich 172.16.0.0/16 Anschließend lassen wir alle anderen Einstellungen auf Default und drücken Create Virtual Cloud Network Bild 4: Anlegen eines Virtuellen Cloud Networks Um aus dem Internet auf das K8s-Cluster zugreifen zu können, wird ein Internet Gateway benötigt. Um es zu erzeugen wählen wir das eben erzeugte "oke-vcn" aus und klicken auf der linken Seite unter Ressourcen auf Internet Gateways. Wir wählen wieder das gewünschte Compartment aus Als Name tragen wir gateway-0 ein Im letzten Schritt klicken wir Create Internet Gateway Bild 5: Anlegen eines Internet Gateways In der Oracle Cloud Infrastructure gilt das Prinzip "Security First", daher muss nach der Erstellung des Internet Gateways, die Routing-Regeln erstellt werden. Hierfür wählen wir im erstellten VCN im linken Bereich den Link Routing Table aus und klicken auf Create Route Table. Wir wählen wieder das gewünschte Compartment aus Als Name tragen wir routetable-0 ein In den Route Rules tragen wir folgendes ein: Target Type: Internet Gateway Destinaction CIDR Block 0.0.0.0/0 Compartment (unser gewähltes Compartment) Target Internet Gateway: gateway-0 Anschließend drücken wir Create Route Table und den Route Table zu erstellen Bild 6: Erstellen eines Routing Tables Nach der Erstellung des VCNs, des Internet-Gateways und des dazugehörigen Routing-Table müssen eine Reihe von Security Lists erstellt werden. Security Lists bieten eine virtuelle Firewall für eine Instanz mit Ein- und Ausgangsregeln, die die ein- und ausgehenden Datenverkehrstypen angeben. Jede Security List wird auf Instanz-Ebene angewendet. Sie konfigurieren jedoch Ihre Security List auf Subnetzebene, was bedeutet, dass alle Instanzen in einem bestimmten Subnetz denselben Regeln unterliegen. Für die Erstellung des K8s-Clusters benötigen Sie eine Security List für die Worker Nodes des Clusters mit folgenden Regeln: Wir wählen wieder das gewünschte Compartment aus Als Security List Name tragen wir sl-workers ein Ingress Rule Source CIDR 172.16.10.0/24 IP Protocol: All Protocols Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 172.16.11.0/24 IP Protocol: All Protocols Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 172.16.12.0/24 IP Protocol: All Protocols Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 0.0.0.0/0 IP Protocol: ICMP Type and Code: 3,4 Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 130.35.0.0/16 IP Protocol: TCP Destination Port Range: 22 Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 138.1.0.0/17 IP Protocol: TCP Destination Port Range: 22 Anschließend klicken sie auf Add Rule Ingress Rule Source CIDR 0.0.0.0/0 IP Protocol: TCP Destination Port Range: 22 Anschließend klicken sie auf Add Rule Egress Rule Source CIDR 0.0.0.0/0 IP Protocol: All Protocols Anschließend klicken sie auf Add Rule Anschließend klicken sie auf Create Security List Bild 7: Zusammenfassung der Regeln der Security List für die Worker-Nodes Eine weitere Security List wird für die beiden Load Balancer Subnetze benötigt, die Security Listen haben folgenden Regel: Wir wählen wieder das gewünschte Compartment aus Als Security List Name tragen wir sl-loadbalancer ein Ingress Rule Source CIDR 0.0.0.0/0 IP Protocol: All Protocols Anschließend klicken sie auf Add Rule Alle Egress Rules müssen entfernt werden. Anschließend klicken sie auf Create Security List Bild 8: Zusammenfassung der Regeln der Security List für die Load Balancer-Nodes II. Anlegen der Subnetze Wie zuvor beschrieben werden drei Subnetze für die Worker-Nodes angelegt und zwei für die Load Balancer. Zum Anlegen der Subnetze für die Worker-Nodes gehen Sie folgendermaßen vor:   Klicken Sie auf Subnets unter den Resources auf der linken Seite der VCN-Seite Dann klicken Sie für das Erstellen des ersten Subnetzes auf Create Subnet Als Name tragen wir workers-1 ein Als Availability Domain wählen wir AD-1 aus CIDR Block: 172.16.10.0/24 Route Table: routetable-0 Subnet Access: Public Subnet DHCP Options: Default DHCP Options Security Lists: sl-workers Anschließend klicken sie auf Create. Dann klicken Sie für das Erstellen des zweiten Subnetzes auf Create Subnet Als Name tragen wir workers-2 ein Als Availability Domain wählen wir AD-2 aus CIDR Block: 172.16.11.0/24 Route Table: routetable-0 Subnet Access: Public Subnet DHCP Options: Default DHCP Options Security Lists: sl-workers Anschließend klicken sie auf Create. Dann klicken Sie für das Erstellen des dritten Subnetzes auf Create Subnet Als Name tragen wir workers-3 ein Als Availability Domain wählen wir AD-3 aus CIDR Block: 172.16.12.0/24 Route Table: routetable-0 Subnet Access: Public Subnet DHCP Options: Default DHCP Options Security Lists: sl-workers Anschließend klicken sie auf Create. Bild 9: Zusammenfassung der Worker-Node-Subnets Zum Anlegen der Subnetze für die Load Balancer gehen Sie folgendermaßen vor: Klicken Sie auf Subnets unter den Resources auf der linken Seite der VCN-Seite Dann klicken Sie für das Erstellen des ersten Subnetzes auf Create Subnet Als Name tragen wir loadbalancer-1 ein Als Availability Domain wählen wir AD-1 aus CIDR Block: 172.16.20.0/24 Route Table: routetable-0 Subnet Access: Public Subnet DHCP Options: Default DHCP Options Security Lists:sl-loadbalancers Anschließend klicken sie auf Create. Dann klicken Sie für das Erstellen des zweiten Subnetzes auf Create Subnet Als Name tragen wir loadbalancer-2 ein Als Availability Domain wählen wir AD-2 aus CIDR Block: 172.16.21.0/24 Route Table: routetable-0 Subnet Access: Public Subnet DHCP Options: Default DHCP Options Security Lists: sl-loadbalancers Anschließend klicken sie auf Create. Bild 10: Zusammenfassung der Load Balancer-Subnets  4. Erstellung des Clusters (ca. 5 Minuten) Im Vergleich zum Erstellen der Netzwerkkomponenten und Security-Regeln ist das Erzeugen des K8s-Cluster in wenigen Schritten durchzuführen. Nachdem das Cluster definiert wurde, geben Sie in der Regel Details für verschiedene Node-Pools im Cluster an (Profile, Formen, Anzahl der CPUs in den Arbeitsknoten, Arbeitsspeicher etc.). Sie können diese Definitionen während der Erstellung oder zu einem späteren Zeitpunkt angeben. Um das K8s-Cluster zu erzeugen: Öffnen Sie das Seitennavigationsmenü und wählen "Developer Services" -> Container Clusters Wählen Sie wieder das gewünschte Compartment aus Klicken Sie auf Create Cluster und tragen Sie folgende Informationen ein: Name des Clusters zum Beispiel "oke-cluster" Tragen Sie die aktuelle Version 1.10.3 des Clusters ein Wählen sie das vorher erstellte VCN "oke-vcn" Verwenden Sie die vorher erstellten Kubernetes Service LB Subnets (loadbalancer-1 und loadbalancer-2) Für den Kubernetes Service CIDR Block können wir 10.96.0.0/16 eintragen der Pods CIDR Block ist 10.244.0.0/16 bei die Additional Add On's können Sie die Default Werte lassen Bild 11: Erzeugen des Oracle Kubernetes Engine Clusters Anschließend klicken Sie Add a Node Pool um die virtuellen Hosts zum K8s-Cluster hinzuzufügen. Für den Namen verwenden Sie einen uniquen Namen wie zum Beispiel "oke-pool" Die Version sollte der vorher ausgewählten entsprechen, in diesem Fall 1.10.3 Für das Image verwenden Sie bitte Oracle-Linux-7.4 In diesem Fall verwenden wie den Shape VM.Standard1.2 Unsere im vorherigen Schritt erstellte Subnets können wir hier einfügen (worker-1, worker-2, worker-3) Die Quantitiy Per Subnet gibt an, wie viele in diesem Fall virtuelle Hosts in einem Subnetz verwendet werden und wir verwenden 1 Host Der Public SSH Key kann dazu verwendet werden, sich auf die Hosts zu verbinden. Man kann dieses Feld auch leer lassen bzw. zu einem späteren Zeitpunkt einen SSH Key auf die Instanz übertragen. Im letzten Schritt klicken Sie Create, um den K8s-Cluster zu erzeugen.  Bild 12: Erzeugen der Oracle Kubernetes Engine Node Pools Anschließend beginnt die Installation und Konfiguration des K8s-Clusters, dieser Vorgang dauert einige Minuten und wird durch den Status "Creating" angezeigt. Wechselt die Anzeige auf Active, können Sie das Cluster verwenden. Während der Erzeugung des Cluster wird ein sogenanntes kubeconfig File erzeugt, dieses wir anschließend dazu verwendet sich mit dem K8s-Cluster zu verbinden. Der externe Zugriff auf das Cluster ist das Thema des nächsten Kapitels. 5. Zugriff auf das Cluster (ca. 20 Minuten) Um das K8s-Cluster von Ihrem Client zu administrieren benötigen Sie folgende Voraussetzungen: kubectl - Dies ist ein Programm zur konsolengestützen Administration eines K8s-Clusters. Die Dokumentation für die Installation finden Sie hier. Oracle Cloud Infrastructure CLI - Ein Command-Line-Tool zur Administration der Oracle Cloud Infrastructure (OCI). Die Installationsdokumentation finden Sie hier, die Konfigurationsdokumentation hier. Einen Public Key für den API-Benutzer - Zur sicheren Kommunikation zwischen Ihren Client und der verwendeten Cloud-API Um den Public-Key für die API in die OCI hochzuladen klicken Sie in der oberen, rechten Ecke auf den Benutzernamen -> User Settings und anschließend auf Add Public Key. Kopieren Sie anschließend den Public-Key in das Fenster und klicken Sie Add. Wenn der Key ordnungsgemäß hochgeladen wurde, sehen Sie den Fingerprint des Keys (zum Beispiel 7f:af:25:20:66:01:2c:8d:5.....). Bild 13: Erzeugen des API-Keys Um auf das Cluster mittels kubectl zugreifen zu können benötigen Sie eine Autorisierung und Authentifizierung. Dieses wird durch das kubeconfig File ermöglicht. Dieses File enthält alle benötigten Informationen, um eine sichere Verbindung zwischen dem kubectl-Client und dem K8s-Cluster zu gewährleisten. Um das File vom Cluster runter laden zu können, müssen Sie erst das get-kubeconfig.sh File herunterladen. In diesem File sind alle Informationen, wie zum Beispiel Endpoints, Identifikationsparameter etc. für das erstellte K8s-Cluster enthalten. Um das File herunterzuladen gehen Sie auf das linke Seitennavigationsmenü und wählen unter der Rubrik Developer Service -> Container Clusters. In der Liste der erstellten K8s-Cluster wählen sie das "oke-cluster" und klicken im oberen Bereich auf den Knopf Access Kubeconfig, in dem nun erscheinenden Pop-Up-Fenster, können Sie das get-kubeconfig.sh File herunterladen. WICHTIG! Bei meinem Versuch das File herunterzuladen hat es nur mit Chrome Browser unter MacOS funktioniert. Safari und Firefox konnten das File nicht herunterladen. Bild 14: Zugriff auf das kubeconfig-File Der Dialog in dem Pop-Up-Fenster, unter dem Download-Buttonanz kann dazu verwendet werden das kubectl zu starten. Der Dialog enthält folgende Befehle, die Sie in einem Linux/Unix-Terminal-Fenster ausführen können: # Machen Sie das Script get-kubeconfig.sh ausführbar chmod +x ~/get-kubeconfig.sh # Endpunkt der Container-Engine (In diesem Fall die Availability Domain 1, in der Region Ashburn US) export ENDPOINT=containerengine.us-ashburn-1.oraclecloud.com # Herunterladen des kubeconfig Files ~/get-kubeconfig.sh ocid1.cluster.oc1.iad.aaaaaaaaafsgcylgmi4tgnzuhaztoojrmm3d******** > ~/kubeconfig   # Setzen der KUBECONFIG-Umgebungsvariable und Abfrage der verschiedenen K8s-Cluster-Knoten mittels kubectl export KUBECONFIG=~/kubeconfig kubectl get nodes Anschließend werden Ihnen die Namen/IP-Adressen, der Status, Role, Age und Version der K8s-Cluster-Knoten angezeigt. 6. Starten des K8s-Dashboards (ca. 5 Minuten) Das K8s-Dashboard ist ein webbasierendes Benutzer-Interface das als Alternative zu kubectl verwendet werden kann. Das Dashboard kann dazu verwendet werden Container-Applikation bereit zu stellen, Monitoring, Troubleshooting und administrative Aufgaben zu übernehmen. Bei dieser Übung wird die Ausgabe des Dashboards mittels Proxy auf den verwendeten Client umgeleitet, dies ist mit wenigen einfachen Schritten durchzuführen. Öffnen Sie ein Terminal-Fenster Setzen Sie die Umgebungsvariable mittels export KUBECONFIG=~/kubeconfig Starten Sie den kubectl Proxy-Server mit folgenden Befehl kubectl proxy Anschließend können Sie in einem Webbrowser ihrer Wahl mit der URL http://127.0.0.1:8001/ui das K8s-Cluster-Dashboard aufrufen. Bild 15: Kubernetes Dashboard Wenn Sie die Dashboard-Seite aufrufen, werden Sie aufgefordert entweder ein Token einzugeben oder das kubectl File zu verwenden. Es wird die zweite Variante empfohlen: Wählen Sie kubeconfig aus und öffnen Sie den lokalen Datei-Browser in dem Sie auf choose kubeconfig file klicken. Wählen Sie die kubeconfig aus und klicken Sie Sign In. In diesem Artikel wird nicht weiter auf die Einzelheiten des K8s-Dashboard eingegangen, die Funktionalitäten sind ausreichend Dokumentiert und es gibt viele Artikel, die sich mit dem Dashboard auseinandersetzten. Ein erster Anlaufpunkt ist die Kubernetes-Dokumentation hier. 7. Bereitstellen einer Cluster-Applikation (ca. 10 Minuten) In dem letzten Kapitel beschäftigen wir uns mit der Bereitsellung einer Container-Applikation in das K8s-Cluster. Wir verwenden den beliebten Apache-Web-Server oder kurz httpd. Um den Web-Server auf dem Cluster bereitzustellen, gehen wir wieder auf die Kommandozeile. Der Web-Server wird folgendermaßen bereitgestellt: Setzen der Kubeconfig Variable mittels export KUBECONFIG=~/kubeconfig Herunterladen und Stagen der ngix Web-Servers mit drei Replikas auf drei verschiedenen Knoten. Erstellen der Apache-Web-Server-Applikation, inklusive automatischer Bereitstellung des Load Balancer-Services Nachdem wir die Umgebungsvariable KUBECONFIG gesetzt haben, laden wir den Apache-Web-Server herunter und verteilen diesen auf drei Cluster-Knoten: kubectl run httpd --image=httpd --port=80 --replicas=3 Das Deployment kann man sich mit dem folgenden Befehl anzeigen lassen: kubectl get deployments Das Deployment ist in diesem Zustand jedoch noch nicht mit externer IP sichtbar, dafür muss das Deployment als Service definiert und mit dem Load Balancer verbunden werden: kubectl expose deployment httpd --port=80 --type=LoadBalancer Anschließend ist der Service extern sichtbar und man kann mit der öffentlichen IP die Startseite des Web-Server sehen. Die öffentliche IP bekommt man durch den Befehl: kubectl get services Oder auch in der OCI-GUI in dem Bereich Load Balancer. Dafür gehe sie auf das linke Seitenleistennavigationsmenü und wählen Netzworking -> Load Balancers, die öffentlich IP steht in der Übersicht des Load Balancer Service. Wenn Sie nun die öffentliche IP in einem Browser eingeben, erscheint die Apache-Startseite mit dem Schriftzug "It works!" Der Load Balancer Service des Oracle Cloud Infrastructur Services ist fest mit dem K8s-Cluster integriert, d.h. der Load Balancer wird mit dem expose Befehl automatisch erzeugt und auch anschließend beim Löschen des Services wieder aufgeräumt. Übrigens: Beim Load Balancer Service handelt es sich nicht um eine VM mit einem installierten Software-Load Balancer, sondern ein "echter" Load Balancer-Service, der auf Netzwerk-Hardware beruht. Bild 16: Apache Default-Startseite = Es funktioniert! Wenn Sie jetzt das Cluster wieder aufräumen wollen, in dem Sie den Service löschen verwenden Sie folgende zwei Befehle im Terminal: kubectl delete service httpd kubectl delete deployments httpd Anschließend haben Sie wieder einen K8s-Cluster ohne Deployments. Sie können sich die Deployments natürlich auch im K8s-Dashboard ansehen. 8. Fazit Das Erstellen eines Full-Managed-Kubernetes-Cluster in der Oracle Cloud Infrastructure setzte einige Schritte voraus. Diese Schritte können natürlich auch in Skripten implementiert werden. Eine Beispiel-Form wäre die Erstellung mittels Terraform. Die meisten Konfigurationen betreffen allerdings die Sicherheit des Systems und es wäre unverantwortlich irgendwelche Ports "per Default" zu öffnen, nur um die Demo-Bereitstellung zu beschleunigen. Die Installation und Konfiguration von Kubernetes auf Oracle Cloud Infrastructure beruht auf dem Open-Source-Produkt und entspricht der frei verfügbaren Version, daher basiert die Abrechnung des Services auch ausschließlich auf den verwendeten IaaS-Komponenten und es werden keine weiteren Gebühren bezüglich Kubernetes-Nutzung erhoben. D.h. es ist kein Unterschied ob Sie einen Oracle Cloud Core (OCPU) nur mit einem Betriebssystem  oder mit der Oracle Kubernetes Engine nutzen, die Kosten sind gleich. Der Vorteil bei der Nutzung des Kubernetes Services auf der Oracle Cloud Infrastructure (OCI) ist die Flexibilität bezüglich Knoten-Maschinen (von 1 OCPU bis einem ganzen Bare-Metal-Servers) und die optimierte Performance, da die OCI ohne Over-Provisioning implementiert wurde und Sie dedizierte Netzwerkbandbreiten und Serverkapazitäten verwenden. 9. Wichtige Links Kubernetes - Offizielle Dokumentation Oracle Cloud Infrastructure Dokumentation - Kubernetes Engine Dokumentation Kubectl - Howto Erstellung eines Private/Public-Key-Paares - Howto Oracle Trial Account - Einstiegsseite    

Kubernetes ist ein Open-Source-Container-Orchestrierungs-Tool ursprünglich entwickelt von Google und anschließend gespendet an die Cloud Native Computing Foundation, in der u.a. auch Oracle Mitglied...

Einstieg

Terraform - Automatische Erstellung einer DBaaS-Instanz in der Oracle Cloud Infrastructure

Dieses Terraform-Tutorial zeigt das automatisierte Erstellen einer Oracle Database as a Service-Umgebung inklusive aller benötigten Komponenten in der Oracle Cloud Infrastructure (OCI). Terraform ermöglicht das automatische Bereitstellen von komplexen Umgebungen, inklusive aller enthaltenen Ressourcen, wie Netzwerken, Firewalls etc. Es dient dem wiederholten Ausführen von Bereitstellungsaufgaben und ermöglicht das leichte Wiederverwenden bzw. Anpassen der verwendeten Skript-Komponenten. Dieses Tutorial ist einfach durchzuführen, die zu tätigenden Anpassungen sind minimal. Das Tutorial ist ideal, um die Arbeitsweise und Funktion von Terraform in der Oracle Cloud Infrastructure zu verstehen. Terraform ist ein Produkt der Firma Hashicorp und bietet eine Implementierung von Infrastructure as Code (IaC). IaC ermöglicht das Bereitstellen und Administrieren von Rechenzentrum-Infrastruktur-Komponenten in der Cloud. Terraform findet Verwendung bei vielen verschiedenen Cloud-Anbietern. Dazu wird eine einheitliche Laufzeitumgebung bereitgestellt, die durch einen individuellen "Provider" ergänzt wird. Der Provider enthält Cloud-Anbieter spezifische Programm-Bibliotheken, die einen Ablauf in der jeweiligen Cloud-Infrastruktur gewährleisten. Die Terraform-Syntax ist weitgehend simpel und leicht nachvollziehbar. Terraform wurde in der Sprache "Go" entwickelt und ist sehr weit verbreitet. Terraform Funktionsweise Terraform ist ein Betriebsunterstützungssystem (Operational Support System, kurz OSS) zur Erstellung, Änderung und Versionierung der Oracle Cloud Infrastructur. Es besteht aus einer Infrastruktur-Beschreibung, diese ist in Textformat und hat eine einfach gehaltene Syntax. Die Infrastruktur-Beschreibung kann vor der eigentlichen Ausführung/Bereitstellung der Komponenten simuliert werden. Die Simulation ermöglicht es, die geplante Ausführung zu kontrollieren und keine unliebsamen "Überraschungen" während der Bereitstellung zu erleben. Die Erstellung der Ressourcen erfolgt unter Berücksichtigung der Abhängigkeiten: Wenn Komponenten parallel bereitgestellt werden können, wird die Ausführung parallelisiert, bei Abhängigkeiten werden diese berücksichtigt. Neben der Planung und Erstellung ist es möglich Konfigurationsänderungen durchzuführen: Terraform ist in der Lage selbst komplexe Änderungen in der Infrastruktur durchzuführen. Die Ergebnisse der Simulation und der Bereitstellung werden lokal gespeichert, Terraform kennt dadurch den aktuellen Status und die Komponenten der Infrastruktur-Komponenten. Für die weitere Konfiguration der Infrastruktur-Komponenten können Tools wie Puppet, Chef, Ansible, SaltStack etc. integriert aus Terraform heraus aufgerufen und ausgeführt werden. ​Wenn Sie das Tutorial ausprobieren wollen und über keinen Oracle Cloud Infrastructure-Account verfügen, können Sie den kostenfreien Oracle Cloud Trial verwenden. Sie können mit dem Trial 30 Tage und mit bis zu 300 $ Guthaben in der Oracle Cloud Infrastructure testen. Wie bei den anderen großen Cloud-Anbietern müssen Sie nur eine gültige Kreditkartennummer hinterlegen. Die Karte wird nicht belastet und ist nur für den Fall, dass Sie ihre Umgebung später kommerziell weiter nutzen wollen. Das Tutorial umfasst ingesamt fünf Schritte: Terraform Einrichtung - Installieren von Terraform und dem Oracle Cloud Infrastructure (OCI) Provider Cloud Credentials ermitteln - Sammlung aller benötigten Daten für die Verbindung mit dem jeweiligen Cloud-Account Parameter-Datei erstellen - Die benötigten Variablen, wie zum Beispiel Datenbank-Größe, Typ etc., werden in einer zentralen Datei abgelegt Erstellen der Netzwerk-Ressourcen - Alle benötigten Netzwerk-Ressourcen-Konfigurationen werden in dieser Datei angegeben Erstellen der Datenbank-Ressource - Alle benötigten Datenbankinformationen werden in dieser Datei angegeben Am Ende dieses Beitrages habe ich im Kapitel Tipps & Tricks noch einige Erfahrungen und Hilfen eingefügt, die Ihnen die Durchführung dieses Tutorials erleichtern. Schritt 1: Terraform einrichten Um das OCI-Terraform-Plugin nutzen zu können, müssen auf Ihrem Client einige Schritte unternommen werden. Terraform ist agentless, d. h. in der OCI-Umgebung müssen keine Agenten oder ähnliches installiert werden. Im ersten Schritt müssen Sie das Terraform Binary für das jeweilige Betriebssystem herunterladen und installieren: https://www.terraform.io/downloads.html. Terraform läuft als sogenanntes Single-Binary-File, d. h. man braucht nur die ausführbare Datei. Wenn man den Pfad zu Terraform in die Benutzer-Bash bzw. in den PATH von Windows einfügt, kann man es aus dem Terminal aus einem beliebigen Verzeichnis aufrufen. Ob man die richtige Datei heruntergeladen hat, lässt sich nach dem Entzippen feststellen. Wenn Sie die Datei "Terraform" aus der Kommandozeile ausführen, erscheint die Onlinehilfe. Nachdem Sie  das Terraform-Basis-Paket installiert haben, müssen Sie den Provider für die Oracle Cloud Infrastructure herunterladen. Laden Sie den zu Ihrem Betriebssytem passenden OCI Terraform-Provider von folgender Webseite https://github.com/oracle/terraform-provider-oci/releases herunter. Das Plugin (terraform-provider-oci_v*) wird anschließend von Ihnen extrahiert und in folgendes Verzeichnis verschoben Unix/Linux/MacOS ins User-Home unter Plugins: ~/.terraform.d/plugins/ Windows ebenfalls unter Plugins: %APPDATA%/terraform.d/plugins/ Damit ist die Installation von Terraform und dem dazugehörigen OCI-Plugin abgeschlossen! Die  dazugehörige Dokumentation finden Sie unter dem folgenden Link: https://github.com/oracle/terraform-provider-oci/blob/master/README.md. Schritt 2: Cloud Credentials ermitteln Im Laufe dieses Tutorials werden einige Informationen benötigt, um auf Ihren OCI-Account zuzugreifen. In diesem Abschnitt erkläre ich Ihnen, welche Informationen dies sind und an welchem Ort Sie die benötigten Informationen finden. Sie benötigen folgende Parameter/Informationen für die Durchführung des Tutorials: Tenancy OCID - Die Oracle Cloud ID der verwendeten Tenancy also Ihrer OCI-Umgebung User OCID - Die Oracle Cloud ID des verwendeten Benutzers Compartment OCID - Die Oracle Cloud ID des verwendeten Comparments Region - Die verwendete OCI Cloud Region, also eine der folgenden (us-ashburn-1, us-phoenix-1, eu-frankfurt-1, uk-london-1 etc.) Private Key/Public Keys (RSA und PEM) Fingerprint Die Tenancy OCID können Sie leicht auf der OCI-Webseite finden, dafür loggen Sie sich in Ihren OCI-Account ein und navigieren auf die Homepage. Die Tenancy OCID finden Sie unten Links im Browser-Fenster. Bild 1: Anzeige der Tenancy OCID Die User OCID ist auch nicht schwer zu finden. Navigieren Sie im oberen, rechten Browser-Bereich unter Identity -> Users und kopieren Sie mittels Copy-Link die User OCID. Wichtig: Für die Verwendung von Terraform in OCI benötigen Sie einen dedizierten OCI-Benutzer. OCI kann auch mit einem Identity Provider (zum Beispiel Oracle IAM Cloud Service) verwendet werden, Terraform benötigt jedoch einen eigenen Benutzer. Bild 2: Aufinden der User-OCID Die Compartment OCID finden Sie, indem Sie im oberen, rechten Browserfenster auf Identity -> Compartments navigieren und sich die gewünschte Compartment OCID kopieren. Die Region befindet sich im oberen, mittleren Bereich des Browser-Fensters. Bild 3: Finden der Compartment OCID und der Regionsbezeichnung Die letzten beiden benötigten Parameter Private- und Public-Key und Fingerprint lassen sich durch das Tool OpenSSL erstellen. Die genaue Vorgehensweise ist in der folgenden Dokumentation Schritt für Schritt erklärt: https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm#How. Der Fingerprint wird ebenfals durch OpenSSL ermittelt, die Beschreibung finden Sie hier: https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm#How3. Beide Verfahren sind allgemein gebräuchlich, um ein Private/Public-Key-Paar und einen Fingerprint zu erstellen. Wichtig: Das hier erstellte Key-Paar ist nicht das Schlüsselpaar, daß Sie für die SSH-Verbindung zu den Instanzen erstellen, das neu erstellte Key-Paar ist im PEM-Format (und nicht im SSH-RSA-Format). Im nächsten Schritt müssen Sie die Public-Key-Datei in ihre OCI-Instanz hochladen, dafür navigieren Sie auf Identity -> Users und klicken auf Ihren OCI-Terraform-Benutzer. Auf der linken Seite sehen Sie den Bereich "API Keys", mit der "Add Public Key"-Schaltfläche können Sie den Datei-Inhalt des eben erstellten öffentlichen Schlüssels hinzufügen. Bild 4: Hinzufügen des Public Keys Der Inhalt der Public-Key-Datei sieht ungefähr so aus: -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQE... ... -----END PUBLIC KEY----- Im letzten Schritt müssen Sie noch ein RSA-SSH-Key-Schlüsselpaar erstellen, um sich später mit dem Betriebssystem der Datenbank verbinden zu können. In dem folgenden externen Tutorial wird erklärt, wie Sie die RSA-SSH-Schlüssel erstellen können: https://docs.us-phoenix-1.oraclecloud.com/Content/Compute/Tasks/managingkeypairs.htm Die in diesem Kapitel ermittelten Informationen ermöglichen Ihnen im nächsten Schritt die Parameter-Datei zu befüllen. Schritt 3: Parameter-Datei erstellen Wichtig: Alle nachfolgenden Datei-Listings können von Ihnen per "Copy & Paste" übernommen werden. Achten Sie nur darauf, daß sich keine editorspezifischen Zeichen in die Datei einschleichen. Terraform ist sehr sensibel bei der Auswertung der Datei-Syntax und es kann vorkommen, dass ein vom Texteditor hinzugefügtes Sonderzeichen einen Fehler bei der Ausführung generiert. Terraform benötigt für den reibungslosen Programmablauf eine Reihe von Informationen, die bestimmte Aufgaben erfüllen. So müssen zum Beispiel genügend Informationen vorhanden sein, um die Ressourcen in der richtigen Umgebung mit den richtigen Parametern bereitzustellen. Diese Parameter werden durch Variablen übergeben. Es gibt verschiedene Möglichkeiten die Variablen mit Informationen zu belegen, eine der effektivsten Varianten ist die Nutzung der sogenannten "terraform.tfvars"-Datei, hierbei werden alle benötigten Variablen in einer Datei definiert, Terraform lädt alle in die Laufzeitumgebung. Die Datei muss den Namen terraform.tfvars haben, nur dann erkennt Terraform diese Datei als Parameter-Datei. Man unterscheidet drei verschiedene Variablen-Typen: Authentifizierungs-Variablen: In diesen Variablen werden die Informationen zum Anmelden und spezifische Providerinformationen gespeichert (zum Beispiel die verwendete OCI-Region, Tenant etc). Parametrisierungs-Variablen: Jede Ressource in Terraform benötigt spezifische Informationen zur Erstellung (zum Beispiel Datenbankversion Größe, etc.). Benutzerspezifische Variablen: Der Benutzer kann eigene Platzhalter verwenden (zum Beispiel Anzeigenamen der Datenbank, Netzwerkname etc.) Damit die jeweiligen Variablen den richtigen Ressourcen-Variablen zugeordnet werden, habe ich eine zweite Datei erzeugt. Hintergrund ist die saubere Trennung zwischen Variablen in der terraform.tfvars-Datei und den Zuordnungen der benutzerspezifischen Variablen, die üblicherweise nicht mehr editiert werden müssen. Die Abarbeitung der Dateien erfolgt nach der alphabetischen bzw. alphanumerischen Reihenfolge, daher ist es von Vorteil, die Datein zu nummerieren, um die richtige Reihenfolge der Ausführung zu gewährleisten. Auch ist die Dateiendung .tf für die Terraform-Ressourcen-Dateien vorgeschrieben. Die einzige Ausnahme stellt die terraform.tfvars-Datei dar, diese Parameter-Datei wird automatisch von Terraform geladen, der Name der Datei sollte nie verändert werden. Das folgende Datei-Listing "terraform.tfvars" beschreibt die Variablenbelegung. Die Werte in Klammern beziehen sich auf Ihre im vorherigen Kapitel gewonnenen Parameter, die Klammern müssen bei der Eingabe der Parameter entfernt werden: # Benutzervariablen tenancy_ocid        ="[Hier muss Ihre tenancy_ocid stehen]" user_ocid           ="[Hier muss Ihre user_ocid stehen]" fingerprint        ="[Hier muss Ihr Fingerprint stehen]" private_key_path    ="[Hier muss Ihr Pfad zum PEM Private Key stehen]" compartment_ocid    ="[Hier muss Ihre compartment_ocid stehen]" region              ="[Hier muss Ihre Region stehen]" # VCN Konfiguration vcn_display_name = "VCN-DB" vcn_cidr_block = "10.0.0.0/16 # DB Konfiguration CPUCoreCount        = "1" DBEdition           = "STANDARD_EDITION" DBAdminPassword    = "DBAdminP4ssword1##" DBName              = "ORCL" CharacterSet        = "AL32UTF8" NCharacterSet      = "AL16UTF16" DBWorkload          = "OLTP" PDBName             = "PDB1" DBVersion           = "18.1.0.0.0" DBDisplayName       = "DBaaS" DBDiskRedundancy    = "HIGH" DBNodeShape         = "VM.Standard1.1" ssh_public_key      = "[hier muss der vollständige Pfad zum RSA SSH-Public-Key stehen]" DBNodeDomainName    = "subnet.vcndb.oraclevcn.com" DBNodeHostName      = "dbaas-host" DataStorageSizeInGB = "256" LicenseModel        = "LICENSE_INCLUDED" NodeCount           = "1" Speichern Sie diese Datei unbedingt unter dem Namen "terraform.tfvars" in Ihrem Arbeitsverzeichnis ab. Die nachfolgende Datei können Sie ohne Änderung übernehmen. Ich habe Sie "01variables.tf" genannt, um sie nach dem Einlesen der terraform.tfvars-Parameter als Erstes ausführen zu lassen. Die Variablen-Datei definiert die Variablen und belegt sie mit den vorher eingegebenen Parameter, zusätzlich wird der OCI-Terraform-Provider mit Informationen versorgt. # Benutzer bzw. Tenant Variable variable "tenancy_ocid" {} variable "user_ocid" {} variable "fingerprint" {} variable "private_key_path" {} variable "compartment_ocid" {} variable "region" {} # VCN Variable variable "vcn_display_name" {} variable "vcn_cidr_block" {} # Provider Informationen provider "oci" {   tenancy_ocid = "${var.tenancy_ocid}"   user_ocid = "${var.user_ocid}"   fingerprint = "${var.fingerprint}"   private_key_path = "${var.private_key_path}"   region = "${var.region}" } # DB Variablen variable "CPUCoreCount" {}         variable "DBEdition" {}             variable "DBAdminPassword" {}         variable "DBName" {}                 variable "CharacterSet" {}         variable "NCharacterSet" {}         variable "DBWorkload" {}             variable "PDBName" {}                 variable "DBVersion" {}             variable "DBDisplayName" {}         variable "DBDiskRedundancy" {}     variable "DBNodeShape" {}             variable "ssh_public_key" {}         variable "DBNodeDomainName" {}     variable "DBNodeHostName" {}         variable "DataStorageSizeInGB" {} variable "LicenseModel" {}         variable "NodeCount" {}    Speichern Sie die Datei unter dem Namen "01variables.tf" in Ihr Arbeitsverzeichnis. Schritt 4: Erstellen der Netzwerk-Ressourcen Bei der Oracle Cloud Infrastructure stehen oft die vielfälltigen Konfigurationsmöglichkeiten des Netzwerks im Vordergrund, daher müssen im ersten Schritt auch die Netzwerkkomponenten angelegt werden. Es werden folgende Komponenten erstellt bzw. konfiguriert: Virtual Cloud Network (VCN) - Das Cloud-Netzwerk, das als Netzwerkumgebung für die anderen Komponenten fungiert. Internet Gateway - Das VCN hat per Default keine externen Verbindungen, daher richtet man das Gateway für den Zugriff auf das öffentliche Internet ein. Routing Table - Das VCN hat ein oder mehrere Routing-Tabellen, die sicherstellen, dass der Datenverkehr an die richtigen Schnittstellen des VCN weitergeleitet wird. In unserem Fall hat die Routing-Tabelle die Regel: Der Datenverkehr mit jeglicher Ziel-IP wird an das Internet-Gateway weitergeleitet. Subnet - Das Subnetz benötigt man, um die Compute-Instanzen miteinander zu verbinden. Erklärungen zu den einzelnen verwendeten Parametern finden Sie unter folgendem Link: https://github.com/oracle/terraform-provider-oci/tree/master/docs. Hier sind Beispiele mit der Definition der Parameter für die einzelnen Komponenten aufgeführt. Das folgende Datei-Listing "02vcn.tf" beschreibt die Bereitstellung der Ressourcen und kann von Ihnen ohne Änderungen übernommen werden. # Erstellen eines Virtual Cloud Netzwerks resource "oci_core_virtual_network" "VCN" {   cidr_block = "${var.vcn_cidr_block}"   dns_label = "vcndb" compartment_id = "${var.compartment_ocid}" display_name = "${var.vcn_display_name}" } # Erstellen eines Internet Gateways resource "oci_core_internet_gateway" "InternetGateway" { compartment_id = "${var.compartment_ocid}" display_name = "TFExampleIG" vcn_id = "${oci_core_virtual_network.VCN.id}" } # Definition der Routing-Tabellen resource "oci_core_default_route_table" "tf-default-route-table" {   manage_default_resource_id = "${oci_core_virtual_network.VCN.default_route_table_id}"   display_name = "tf-default-route-table"   route_rules {     cidr_block = "0.0.0.0/0"     network_entity_id = "${oci_core_internet_gateway.InternetGateway.id}"   } } # Erstellen eines Subnetzes resource "oci_core_subnet" "DBaaS-Subnet" {   availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[0],"name")}"   cidr_block = "10.0.0.0/24"   display_name = "DBaaS-Subnet"   dns_label = "subnet"   compartment_id = "${var.compartment_ocid}"   vcn_id = "${oci_core_virtual_network.VCN.id}}"   security_list_ids = ["${oci_core_virtual_network.VCN.default_security_list_id}"]   compartment_id = "${var.compartment_ocid}"  vcn_id = "${oci_core_virtual_network.VCN.id}"   route_table_id = "${oci_core_virtual_network.VCN.default_route_table_id}"   dhcp_options_id = "${oci_core_virtual_network.VCN.default_dhcp_options_id}" } # Abfrage der vorhandenen Availability-Domänen data "oci_identity_availability_domains" "ADs" {   compartment_id = "${var.tenancy_ocid}" } Speichern Sie die Datei unter dem Namen "02vcn.tf" in Ihr Arbeitsverzeichnis Schritt 5: Erstellen der Datenbank-Ressource Das Erstellen der Datenbank ist der letzte Schritt. Alle in der terraform.tfvars übergebenen Variablen werden in der folgenden Terraform-Datei genutzt, um die Datenbank mit den gewünschten Parametern bereitzustellen. In diesem Beispiel wird eine Container-Datenbank mit einer Default-Pluggable-Datenbank erzeugt. Erklärungen zu den einzelnen verwendeten Parametern finden Sie unter folgendem Link: https://github.com/oracle/terraform-provider-oci/tree/master/docs. Hier sind Beispiele mit der Definition der Parameter für die einzelnen Komponenten aufgeführt. Das folgende Datei-Listing "03db.tf" beschreibt die Bereitstellung der Ressourcen, Sie können die Datei ohne Änderungen übernehmen. resource "oci_database_db_system" "TFDBNode" {   availability_domain = "${lookup(data.oci_identity_availability_domains.ADs.availability_domains[0],"name")}"   compartment_id = "${var.compartment_ocid}"   cpu_core_count = "${var.CPUCoreCount}"   database_edition = "${var.DBEdition}"   db_home {     database {       "admin_password" = "${var.DBAdminPassword}"       "db_name" = "${var.DBName}"       "character_set" = "${var.CharacterSet}"       "ncharacter_set" = "${var.NCharacterSet}"       "db_workload" = "${var.DBWorkload}"       "pdb_name" = "${var.PDBName}"     }     db_version = "${var.DBVersion}"     display_name = "${var.DBDisplayName}"   }   disk_redundancy = "${var.DBDiskRedundancy}"   shape = "${var.DBNodeShape}"   subnet_id = "${oci_core_subnet.DBaaS-Subnet.id}"   ssh_public_keys = ["${trimspace(file(var.ssh_public_key))}"]   domain = "${var.DBNodeDomainName}"   hostname = "${var.DBNodeHostName}"   data_storage_percentage = "40"   data_storage_size_in_gb = "${var.DataStorageSizeInGB}"   license_model = "${var.LicenseModel}"   node_count = "${var.NodeCount}" } Speichern Sie die Datei unter dem Namen "03db.tf" in Ihr Arbeitsverzeichnis Anlegen aller Ressourcen mit Terraform Nach der Durchführung aller Schritte sollten Sie jetzt in Ihrem Arbeitsverzeichnis vier Dateien mit den Namen: terraform.tfvars 01variables.tf 02vcn.tf 03db.tf haben. Navigieren Sie in das Verzeichnis und initialisieren Sie Terraform mit dem nachfolgenden Befehl:   terraform init Dieser Befehl initialisiert das Arbeitsverzeichnis als Terraform-Umgebung und legt eine Reihe von Terraform-internen Dateien an. In diesen wird zum Beispiel der aktuelle Status der Bereitstellung gespeichert. Mit dem nächsten Befehl zeigen Sie den Ausführungsplan an. Der Ausführungsplan gibt an, welche Komponenten angelegt werden und welche schon vorhanden sind. Terraform ermöglicht es zum Beispiel, bestehende Umgebungen mit neuen Ressourcen zu versorgen oder Änderungen an bestehenden Ressourcen durchzuführen. Der Befehl zum Anzeigen des Ausführungsplans lautet:   terraform plan Der folgende Befehl legt die geplanten Ressourcen an. Die Ausführung kann je nach Ressourcentyp und Architektur zwischen wenigen Minuten und Stunden dauern. Terraform gibt alle 10 Sekunden einen Status zurück, so lange der Status angezeigt wird, ist mit der Ausführung alles in Ordnung.   terraform apply In diesem speziellen Fall wird das Terraform Skript ca. eine Stunde und zehn Minuten laufen. Die Netzwerkkomponenten werden schon nach wenigen Minuten in der OCI-Browser-Oberfläche angezeigt, die Datenbank braucht etwas länger. Wenn Sie nach dem erfolgreichen Anlegen der Datenbank die Umgebung wieder löschen wollen, können Sie dies mit einem Befehl durchführen:   terraform destroy Dieser Befehl löscht alle angelegten Ressourcen und stellt den vorherigen Zustand ihres OCI-Umgebung wieder her. Tipps & Tricks Zum Debuggen der Skripte können Sie den Log-Level von Terraform hochsetzen, dies erreichen Sie durch ein Setzen der Umgebungsvariable TF_LOG=DEBUG. Anschließend sehen Sie alle internen Terraform-Meldungen bei der Ausführung von z. B. terraform plan. Wenn es zu "merkwürdigen" Fehlermeldungen bei der Ausführung kommt bzw. Terraform schon kurz nach dem Aufruf abbricht, kann es helfen, die Statusdateien zu löschen. Diese heißen terraform.tfstate und terraform.tfstate.backup. Durch Ausnahmen in der Programmausführung kann es passieren, dass der Ausführungsstatus einen inkonsistenten Stand hat. In einer Sandbox-Umgebung kann man keinen Schaden anrichten, wenn man die beiden Statusdateien löscht. Wenn Sie nicht Ihren Desktop-Client verwenden wollen, um dieses Tutorial durchzuführen, können Sie auch in der Oracle Cloud Infrastructure eine Oracle Linux-Instanz anlegen und auf dieser arbeiten. Sie müssen allerdings die Instanz so einrichten, dass Sie die benötigten Dateien auf die erstellte Instanz kopieren. Es gibt gute Texteditoren, die die Terraform-Syntax unterstützt. Unter https://www.sublimetext.com oder https://atom.io können Sie den jeweiligen Editor herunterladen. Allerdings müssen Sie bei beiden Editoren die Terraform-Plugins für die Text-Untersütztung installieren, dies ist auf den jeweiligen Webseiten beschrieben (suche nach Terraform). Fazit Terraform ist ein extrem leistungsfähiges Tool, die Erstellung, Veränderung und das Löschen von einfachen und komplexen Infrastruktur-Architekturen ist schnell durchführbar. Die Syntax ist gut zu lesen und zu verstehen und schnell auf verschiedene Anforderungen anzupassen. Ich hoffe, Sie konnten dem Tutorial gut folgen und alle Komponenten bereitstellen. Sie können natürlich die bereitgestellten Skripte verändern und ggf. weiterentwickeln, spielen Sie einfach ein bisschen damit und Sie werden ein besseres Verständnis für die Arbeitsweise von Terraform entwickeln.      

Dieses Terraform-Tutorial zeigt das automatisierte Erstellen einer Oracle Database as a Service-Umgebung inklusive aller benötigten Komponenten in der Oracle Cloud Infrastructure (OCI). Terraform...

Willkommen...

... im Bereich Cloud Technologies der Oracle Deutschland B.V. & Co. KG.  Hier finden Sie Themen rund um Oracle Technologien, die on-premise oder in der Oracle Public Cloud Verwendung finden.  Espressi Hier finden Sie unsere Espresso Reihe. Technologie kurz und knackig auch für Nicht-Techniker erklärt. Zu den Epressi >>> Einstieg in die Oracle Cloud Wie funktioniert die Oracle Public Cloud? Wie wird ein Cloud Services angelegt und genutzt? Wie wird eine hybride Infrastruktur unterstützt? Was bieten die Oracle Rechenzentren in Deutschland? Weitere Informationen >>> IaaS und PaaS Für den Betrieb unserer IaaS, PaaS und SaaS Services, gibt es drei verschiedene Möglichkeiten: in weltweit verfügbaren Cloud Data Center, in eigenen Rechenzentren oder als hybrides Modell. Unterschiedliche Verfügbarkeits- und Netzwerkkonzepte stehen zur Auswahl. Weitere Informationen >>> Datenmanagement, Big Data und Analytics Selbstverständlich ist die on-premise Oracle Datenbank mit gleicher Funktionalität auch in der Cloud als Service verfügbar. Im Umgang mit sehr großen Datenmengen - sowohl strukturiert als auch unstrukturiert - werden geeignete Konzepte, Lösungen und Analysemethoden bereitgestellt. Weitere Informationen >>> Security Die für eine sichere Nutzung der Services notwendigen Verantwortlichkeiten werden durch umfassende dokumentierte Prozesse geregelt und fliessen in die Auftragsdatenverarbeitung ein. Je nach Service liegen Zertifizierungen für Compliance Anforderungen vor oder können durch bestehende technische und organisatorische Maßnahmen von Oracle oder den Kunden abgebildet werden.  Weitere Informationen >>> Cloud Development Folgende Merkmale kennzeichnen das Entwickeln in der Cloud: Laufzeitumgebungen (z.B. Container), Low-Code Umgebungen, verschiedene Programmiersprachen und DevOps Prozessmodelle. Oracle bietet in allen diesen Bereichen entsprechende Cloud Services an, um dem Nutzer größtmögliche Wahlfreiheit einzuräumen. Weitere Informationen >>> Service Integration Oracle bietet verschiedene Cloud Plattformen für die Integration und Zusammenstellung von Services. Diese decken das gesamte Spektrum von feingranular wie bei IoT, leichtgewichtig wie bei „Mobile“ bis schwergewichtig bei Geschäftsprozessen (z.B. SOA) ab. Integrationskomponenten innerhalb und außerhalb der Oracle Produktwelt, stehen ebenfalls zur Verfügung. Weitere Informationen >>>

... im Bereich Cloud Technologies der Oracle Deutschland B.V. & Co. KG.  Hier finden Sie Themen rund um Oracle Technologien, die on-premise oder in der Oracle Public Cloud Verwendung finden.  EspressiHi...

Sicherheit

Sammlung zu Oracle und Datenschutzgrundverordnung (EU DSGVO bzw. GDPR)

Informationen zu Oracle und DSGVO sind verfügbar in  Vertragsbestandteilen bei der Nutzung von Komponenten und Services Informationen in Whitepapern die beschreiben wie Komponenten von Oracle bzgl. DSGVO Anforderungen unterstützen können. Dies umfasst sowohl präventive Aspekte wie Verschlüsselung als auch Nachweis und (kontinuierliche) Kontrolle.  Informationen die unabhängig von Regularien darstellen wie Technologien genutzt werden können. Die beschriebene Nutzung kann durchaus sinnvoll sein im Bereich der DSGVO wie z.B. Dokumentation und Management gespeicherter Daten in verschiedenen Datenhaltungen.    zu 1. Oracle beschreibt bei der Nutzung von Cloudangeboten die Unterstützung bzgl. der DSGVO in unterschiedlichen Vertragsdokumenten. Für die Nutzung von Cloud Services sind diese hier aufgelistet: http://www.oracle.com/us/corporate/contracts/cloud-services/index.html Es kommen allgemeine, service-übergreifende Dokumente wie das "Data Processing Agreement", kurz DPA, zur Anwendung als auch service-spezifische Beschreibungen. Zum DPA gibt es auch unter der oben gelisteten Seite ein Dokument dass die einzelnen Artikel der DSGVO einzelnen Kapitel der DPA zuordnet.   zu 3. Für ein besseres Verständnis helfen darüberhinaus Whitepaper. Diese beschreiben losgelöst von Regulatorien technische und organisatorische Maßnahmen wie z.B. für das Cloud Rechenzentrum und die Services in Frankfurt. Andere Beschreibungen enthalten mögliche Vorgehensweisen zur Erfassung, Dokumentation und dem Management gespeicherter Daten in verschiedenen Datenhaltungen.    zu 2. Daneben gibt es Whitepaper die konkret technische Unterstützungen im Bereich DSGVO aufführen.  Ein Überblickspapier skizziert die eine mögliche Herangehensweise im Rahmen der DSGVO und Mappings von Oracle Komponenten. Einzelne spezifische Whitepaper beschreiben konkrete Technologien wie z.B. im Bereich Datenbanken. Die Informationen sind bei Oracle wie folgt gruppiert: GDPR Resource Center enthält Informationen von Oracle und Analysten zum Thema DSGVO. Hier sind auch die Whitepaper zu Datenbanken, Identity&Access Management, CASB etc. zu finden. Link: https://www.oracle.com/uk/corporate/features/gdpr.html GDPR for Applications enthält Informationen zu den SaaS Angeboten und DSGVO. Link: https://www.oracle.com/applications/gdpr/index.html Spezielle Informationen bzgl. DSGVO gibt es auch zur Marketing Cloud unter folgendem Link: https://www.oracle.com/marketingcloud/about/events/gdpr.html

Informationen zu Oracle und DSGVO sind verfügbar in  Vertragsbestandteilen bei der Nutzung von Komponenten und Services Informationen in Whitepapern die beschreiben wie Komponenten von Oracle bzgl....

Integrationen

Neu: Oracle Integration Cloud – Moderne Integration und intelligente Prozessautomatisierung

In der neuen Oracle Integration Cloud* sind alle Aspekte einer hybriden Unternehmensintegration in einer Plattform vereint. Diese vereinfacht die hybride (Cloud2Cloud und Cloud2OnPremises) Applikationsintegration, Prozessautomatisierung und das adapative Case Management. Dank vordefinierter Rezepte, vorgefertigter Integrationen, 50+ sofort einsatzbereiter SaaS und On Premises Adapter und visueller Modellierungswerkzeuge ist die Nutzung derart vereinfacht, dass diese an Sich anspruchsvollen Integrationsaufgaben sogar direkt aus den Fachabteilungen heraus bewerkstelligt werden können. Zudem ist eine Umgebung für die visuelle Applikationsentwicklung und -Erweiterung, operative Analysen und Datenstromverarbeitung beinhaltet. (*Nicht zu verwechseln mit dem Oracle Integration Cloud Service, der nun aber essentieller Bestandteil der Oracle Integration Cloud Plattform ist) In wenigen Minuten steht mit der Integration Cloud eine Plattform zur Verfügung, um mit wenig bis gar keiner Codierung echte Unternehmenslösungen zu erstellen, die allen Anforderungen an Sicherheit, Verfügbarkeit und Performanz einer unternehmenskritischen Applikation erfüllt. Folgendes sind die Kernfunktionen der Plattform: Applikationsintegration: Aus SaaS Applikationen beliebiger Cloud-Anbieter und Anwendungen im eigenen Rechenzentrum durchgehende Geschäftsabläufe definieren. Dank vorgefertigter Adapter und vereinfachter Werkzeuge bis zu 6x schneller, als mit klassischen Ansätzen (Service Bus & Co.). Prozessautomatisierung: Wiederkehrende Abläufe und Aufgaben zwischen Mitarbeitern, Kunden, Partnern und den involvierten technischen Systemen als transparenten, automatisierten Prozess abbilden und auf beliebigen Endgeräten bereitstellen. Geschäftseinblick: Enblicke in die Abläufe im Unternehmen in Echtzeit. Integrationen und Datenströme analysieren, um Entscheidern KPIs und die aus betriebswirtschaftlicher Sicht beste nächste Aktion vorschlagen zu können. Visual Builder: Mit visuellen Werkzeugen und wenig bis keinerlei Codierung bestehende Applikationen erweitern und schnell neue Applikationen für beliebige Endgeräte entwickeln. Die Oracle Integration Cloud ist in zwei Varianten erhältlich: Standard: beinhaltet die (SaaS und Techologie) Integrationsadapter, den Visual Builder und den Scheduled File Transfer Enterprise: zusätzlich zur Funktionalität der Standard Edition ist die Prozessmodellierung, das Adaptive Case Management, Bisiness Insight und Stream Analytics beinhaltet. Beide Varianten können im Pay-As-You-Go Modell oder monatlich flexibel als OCPU/Stunde bei unbegrenzter Zahl von Verbindungen bezogen werden. Preise: https://cloud.oracle.com/OIC/pricing Weiterführende Informationen und Demovideos: https://cloud.oracle.com/en_US/OIC/videos

In der neuen Oracle Integration Cloud* sind alle Aspekte einer hybriden Unternehmensintegration in einer Plattform vereint. Diese vereinfacht die hybride (Cloud2Cloud und Cloud2OnPremises) Applikations...

Einstieg

Allgemeine Anforderungen bei Regularien

Im Prinzip gibt es mit der Nutzung von IT keinen Bereich der nicht von Regularien betroffen ist. Dies gilt insbesondere für Unternehmen, die teilweise branchenspezifische Regelungen erfüllen müssen aber auch im Vereins- und Privatbereich. Die verschiedenen Regularien enthalten Anforderungen in einer unterschiedlichen Detailtiefe, beispielsweise eine umgangssprachige Formulierung wie State-of-the-Art (GDPR Artikel 32) oder technisch spezifisch wie starke Authentifizierung (PCI-DSS Kapitel 8.3. Incorporate two-factor authentication for remote network). Daneben gibt es Anforderungen zur Sicherstellung des Betriebs wie bei KRITIS und viele organisatorische Themen. Regularien tragen in sich weiterhin natürlich einen juristischen Aspekt, der hier nicht betrachtet wird. Für eine konkrete Spezifizierung der Umsetzung ist der entsprechende Bereich in Ihrem Hause verantwortlich. Zum Thema DSGVO finden Sie unter diesem Link eine Zusammenstellung von material von Oracle. Schlüsseltechnologien Werden die technischen Anforderungen verallgemeinert so kristallisieren sich über viele Regularien einige Schlüsseltechnolgien oder auch Patterns heraus. In der folgenden Artikelserie erfolgt eine technologische Betrachtung solcher Schlüsseltechnologien im Bereich Datenhaltung, Identity/Access Management und Monitoring. Diese Technologien sind gruppiert nach folgenden Themen: Datenschutz: Verschlüsselung von Daten gegen unbefugtes Lesen Zugriffsbeschränkung Anonymisierung und Pseudonymisierung von Daten Umsetzung von Löschkonzepten bzw. Löschfristen Monitoring Identity Governance Access Management Weiterführende Themen wie Enterprise Data Quality Managmenent / Master Data Management oder Unterstützung mit Hilfe von Hardware erfolgen zu einem späteren Zeitpunkt. Status Quo? Typischerweise erfolgt vor der Umsetzung von Massnahmen die Aufnahme des Status Quo in zwei Schritten: Welche Massnahmen sind schon umgesetzt oder projektiert? Wo befinden sich im Unternehmen oder von genutzten Clouds Daten, Systeme oder Prozesse die darüberhinaus von Regularien betroffen sind? Zu Punkt 2 gibt es einige Hilfestellungen, beispielsweise im Bereich Oracle Datenbanken: Analyse der Konfigurationen gegen best practices Analyse genutzter Berechtigungen in der Datenbank Entdecken von möglichen sensitiven Daten in der Datenbank Überprüfung der Konfiguration gegen externe Regelwerke wie STIG oder CIS

Im Prinzip gibt es mit der Nutzung von IT keinen Bereich der nicht von Regularien betroffen ist. Dies gilt insbesondere für Unternehmen, die teilweise branchenspezifische Regelungen erfüllen müssen...

Datenverwaltung

Security Artikel zu Oracle Datenbanken

Oracle Datenbanken haben bezüglich Security Funktionen eine lange Historie. Angefangen mit Themen wie eine ausgelagerte Authentifizierung, das Einbinden einer starken Authentifizierung, einer in ein LDAP ausgelagerten Authorisierung, Verschlüsselung, Zugriffsbeschränkung, Audit und DB Firewall sind die neuesten Themen eine über Audit Vault / Enterprise Manager hinausgehende SIEM Funktionalität und letztendlich die Autonomous Database, angekündigt anlässlich der OOW 2017. Artikel zu diesen Themen sind in einem weiteren Blog zu finden. Beispiele dazu sind  Anonymisierung von Daten in der Oracle Datenbank: wie funktioniert das? Wir werden immer wieder danach gefragt wie Anonymisierung in der Datenbank funktioniert. Je nach Anforderung bietet die Oracle Datenbank dazu verschiedene Möglichkeiten wie zum Beispiel Virtual Private Database Data Redaction und Data Masking.   Überprüfung der Datensicherheit mit Database Security Assessment Tool Datenbanken sollten so konfiguriert werden, dass sie ausschließlich nur Funktionen zulassen, die für den Betrieb der Anwendungen beziehungsweise der Verfahren notwendig sind. Für jedes Datenbanksystem, welches personenbezogene Daten verarbeitet, muss ein Grundschutz implementiert werden.   12.2 Security: Fully Encrypted Database und TDE Live-Conversion Das meist eingesetzte Sicherheitsfeature für die Oracle Datenbank ist Transparent Data Encryption (TDE). Eingeführt wurde die Oracle Datenbank-Verschlüsselungstechnologie bereits 2005 mit der Datenbank Version 10.2.  Seitdem wurde sie von Version zu Version stetig erweitert und der Funktionsumfang vergrößert.   Härtung der Datenbank mit Security Technical Implementation Guide?   Hier die Liste zu allen gebloggten Security Einträgen. Aktuelle Dokumentation 12c R2 Database Security.  

Oracle Datenbanken haben bezüglich Security Funktionen eine lange Historie. Angefangen mit Themen wie eine ausgelagerte Authentifizierung, das Einbinden einer starken Authentifizierung, einer in ein...

Sicherheit

Monitoring und Cyber-Security, Oracle Security Information and Event Management

Mit der wachsenden Zahl an on-premises und Cloud-Umgebungen steigt der Aufwand alle diese Umgebungen zu monitoren. Mit der Zunahme von Cyber-Attacken im Gegensatz zu den „einfachen“ Datenabgriffen der Vergangenheit wird das bisherige Security Monitoring heute auf den Prüfstand gestellt. Oracle stellt mit dem Oracle Enterprise Manager seit längerem ein Werkzeug zum Monitoring der on-premises und Cloudinstallationen zur Verfügung. Der hier vorgestellte Ansatz legt andere, cloudbasierte Monitoringwerkzeuge von Oracle zugrunde die über den Enterprise Manager hinausgehen. Zentrale Elemente des Monitorings bezüglich Security und Compliance sind: Die Überprüfung hinsichtlich der Aktionen in einzelnen Systemen und über Systeme hinweg Eine fortwährende Prüfung der Konfiguration hinsichtlich der Unternehmens- und Compliancevorgaben Dieses Monitoring wird meist toolbasiert in SIEM (Security Information and Event Management) Systemen durchgeführt und durch ein NOC/SOC (Network Operation Center / Security Operation Center) betrieben. Traditionelle Ansätze sind typischerweise regelbasiert und arbeitsaufwändig. Dies birgt Herausforderungen an folgenden Stellen: Abwehr von Cyber-Attacken:  Angriffe lassen sich nicht mehr nur durch Regeln erkennen, da sie über mehrere Stufen und Systeme hinweg über einen längeren Zeitraum aufgebaut sind. Steigerung der Agilität: Business-Verantwortliche erwarten Anwendungen und Erweiterungen immer schneller in Produktion zu bringen. Damit haben die Security-Verantwortlichen kaum oder keine Zeit die Regelwerke anzupassen. Mit der Einführung von DevOps Entwicklungsprozessen erfolgen Änderungen zudem stetig, so dass vorab eine Definition von Regeln teilweise nicht mehr eingeplant ist. Absicherung extern genutzter Cloudservices: In das Monitoring müssen auch externe Cloud-Anbieter einbezogen werden. Dass dies kein abstraktes Beispiel ist zeigen die verschiedenen Datenabflüsse 2017 bei Deloitte und Verizon. Gängige SOC Methoden haben diese Anforderungen adaptiert. Da die meisten dieser Aufgaben manuell erledigt werden, führt dies zu einer Überlastung der SOC-Spezialisten. Der Ansatz ist nun nicht nur gegen Regelwerke wie bei bisherigen Lösungen zu prüfen sondern zusätzlich "Machine Learning" Algorithmen für eine weitere Automatisierung einzusetzen. Diese müssen vorkonfiguriert und ohne Zusatzaufwände durch Spezialisten einsetzbar sein. Damit können viele der bisherigen manuellen Schritte im SOC automatisiert werden, unter anderem das Bilden der sogenannten User and Entity Behavior Analytics (UEBA), Call Trees, Kill Chain Discoverys, Vorhersagen oder "nur" die Erkennung von allgemeinen Korrelationen und Mustern. Diese Funktionen werden von verschiedenen Oracle Lösungskomponenten bereitgestellt. Sie bieten vorgefertigte Integrationen zu Systemen und nutzen einen unterliegenden Big Data Ansatz um die „beliebig“ wachsenden Daten in den Griff zu bekommen. Die Komponenten sind im Einzelnen: Oracle Management Cloud Security Monitoring Analytics (OMC SMA) zum Monitoring der Plattformen ob on-premises oder in der Cloud Oracle Management Cloud Compliance Control (OMC CC) zur Prüfung der Konfigurationen gegen Unternehmensvorgaben oder externe Regelwerke  Oracle Cloud Access Security Broker (Oracle CASB) zum entdecken einer Schatten-IT in der Cloud und  der Überwachung von Unternehmensvorgaben bezüglich Nutzung und Konfiguration von Oracle und 3rd Party Cloud Diensten wie AWS, Salesforce, Azure, Box etc. Oracle Identity Cloud Service (Oracle IDCS) für die Bereitstellen eines Benutzerverwaltungs- und Authentifizierungssystem für on-premises oder Cloud Services In der folgenden Abbildung stellt die Oracle Management Cloud das aggregierende Dashboard. Abhängig von der Aufgabenstellung kann das auch ein anderes SIEM oder CASB System übernehmen: Zusammenfassung und Ausblick Die klassischen SIEM und SOC Plattformen haben sich weiterentwickelt. Der SOC Spezialist ist nicht mehr alleine die Drehscheibe um SIEM Informationen bzw. Alarme zu bewerten. Algorithmen aus dem Bereich Machine Learning oder der Datenanalyse übernehmen nun das Aussortieren von relevanten Daten und leiten ggf. eine automatisierte Behandlung ein. In Ausnahmefällen wird an die SOC Spezialisten eskaliert um eine manuelle Bearbeitung durchzuführen. Damit kann eine Reduzierung der tagtäglichen SOC Arbeiten erreicht und so die Kapazitäten für herausfordernde Fälle genutzt werden. Durch die Automatisierung ist es so möglich mehr Komponenten zu monitoren und bei komplexeren Angriffen besser gerüstet zu sein. Oracle Management Cloud Security Monitoring Analytics, Oracle Management Cloud Compliance Control, Oracle Cloud Access Security Broker und Oracle Identity Cloud Service bieten eine entsprechende SIEM/SOC cloudbasierte Plattform zur Überwachung von on-premises und cloudbasierten Diensten. Die Komponenten können einzeln oder zusammen eingesetzt und natürlich auch in andere SIEM Systeme und Cloud Security Monitoring Services als Quelle integriert werden. Weitere Informationen Tests sowie weitere Informationen und Dokumentation unter: Security Monitoring: https://cloud.oracle.com/en_US/security-analytics Configuration & Compliance: https://cloud.oracle.com/en_US/compliance CASB: https://cloud.oracle.com/en_US/casb IDCS: https://cloud.oracle.com/en_US/idcs Monitoring mit dem Cloud Access Security Broker (CASB) Weiterführende Informationen zu Security & Oracle im Internet unter http://www.oracle.com/security und https://www.oracle.com/cloud/security/index.html Ein ausführlicheres Whitepaper finden Sie hier.

Mit der wachsenden Zahl an on-premises und Cloud-Umgebungen steigt der Aufwand alle diese Umgebungen zu monitoren. Mit der Zunahme von Cyber-Attacken im Gegensatz zu den „einfachen“ Datenabgriffen der...

CloudDev

Einstieg in die Blockchain Technologie mit dem Oracle Blockchain Cloud Service

Beitrag von Marcel Boermann, Oracle Architect for Cloud & IT Technologies, ORACLE Deutschland B.V. & Co. KG   Interessante neue Technologien wie die sogenannten Blockchains sind inzwischen herangereift und suchen bzw. finden im Moment in nahezu allen Industriezweigen zahlreiche Anwendungsgebiete. Bekannt geworden sind Blockchains beispielsweise durch Krypto-Währungen wie Bitcoin und Crowd Funding Projekte auf Basis von Ethereum , sind inzwischen herangereift und suchen bzw. finden im Moment in nahezu allen Industriezweigen zahlreiche Anwendungsgebiete.     Wie sieht eine Blockchain aus? Bei einer Blockchain handelt es sich, grob gesagt, um ein verteiltes Peer-to-Peer Netzwerk, das in Summe und einvernehmlich ein fortlaufendes Journal führt. Jeder Peer pflegt seine eigene Kopie des Journals und jedes Journal ist synchronisiert mit allen anderen Beteiligten im Netzwerk. Das Journal kann beliebige Daten enthalten, also längst nicht nur die Protokolle von Transfers virtueller Währungen. Diese Daten werden in vom Netzwerk festgelegter, abgestimmter Reihenfolge in das Journal gespeichert. Aktuelle Daten werden oftmals digital signiert und per Hashwert verkettet mit den zuletzt geschriebenen Daten, so daß eine unveränderbare, sichere Kette von Datenblöcken entsteht, die fortlaufend geschrieben wird. Das Konzept ist grob vergleichbar mit dem Transaktionslog einer Oracle Datenbank, welches jedoch von mehreren Prozessen unterschiedlicher Hoheiten parallel und abgestimmt geführt wird. Jeder Datenblock ist in mathematischer Abhängigkeit zum zuletzt geschriebenen Datenblock und bei Bedarf verschlüsselt. Wofür lassen sich Blockchains verwenden ? Eine Blockchain löst ein altes Problem bei der Interaktion mehrerer Parteien. Bei Austausch heikler oder sensibler Daten wurde oft eine neutrale, von allen Parteien akzeptierte Instanz gewählt. Diese Instanz ist eine Art Notarfunktion, die Buch führt und nachweist, dass ein Austausch stattgefunden hat, inklusive Informationen wie wann, mit wem und mit welchem Inhalt. Beispielsweise welches Haus, wieviel Geld, welches Autoteil, usw.. Doch was tut man, wenn diese dritte Instanz zur Koordination zu träge wäre oder man sich nicht auf einen gemeinsamen Treuhänder einigen kann? Eine mögliche Lösung ist wenn jede Partei selbst Buch führt und sich die Parteien untereinander abstimmen. Die Abstimmung beinhaltet die Gültigkeit des gerade bearbeiteten Datensatzes und die Reihenfolge um den Datensatz in den nächsten Block in eine Kette von Blöcken zu schreiben. Ein Block kann mehrere Datensätze enthalten.  Ein solchermaßen mehrparteilich einvernehmliches und unverfälschliches Protokoll wird auch Hauptbuch (Ledger) genannt. Es kann in vielen Szenarien angewendet werden, um eine zusätzliche Stufe der Sicherheit und Nachvollziehbarkeit zu erwirken. Lediglich eine juristische Anerkennung solcher Logs ist noch nicht erfolgt. Dennoch werden unter anderem im Bereich finanzieller Mikro-Transaktionen, automatisierten Trades im Energie- und Finanzbereich und bei der Nachvollziehbarkeit von Lieferketten mittlerweile Blockchains zusätzlich zu bisherigen Mitteln eingesetzt und in bestehende Systeme integriert.  Der Oracle Blockchain Cloud Service Oracle bietet den Autonomous Blockchain Cloud Service an, der als „enterprise grade“ Blockchain mit mehreren Mandanten bzw. Parteien eingesetzt werden kann. Eine Integration in Oracle SaaS Angebote ist vorhanden. Ein vollständiges Blockchain Netzwerk kann mit dem neuen Service einfach per Cloud Portal aufgesetzt werden. Ein aufwendiges Durcharbeiten der Voraussetzungen und benötigter technischer Komponenten inklusive Installationsprozesse mit zahlreichen Docker Containern und komplexer Netzwerk-Infrastruktur ist nicht notwendig. Die Administrations-Oberfläche zeigt den Zustand der Komponenten und ermöglicht die Verwaltung von sogenannten Chaincodes. Diese lege fest welche Daten in die Blockchain gelangen und was mit den Daten möglich ist. Zum Beispiel die Historie eines Datenobjektes auszulesen oder Inhalte von Datenobjekten (auch „Asset“ genannt) zu prüfen oder beliebige Regeln auf Objekte, Attribute und beteiligte Parteien anzuwenden. Sogenannte Smart Contracts implementieren dies, sie definieren die beim geschäftlichen Austausch mehrerer Parteien auszuführende Logik und das Geschäftsprotokoll.   Die Technik unter dem Oracle Blockchain Cloud Service Der Oracle Blockchain Cloud Service basiert auf dem populären Hyperledger Fabric Framework, der unter anderem von IBM entwickelt wurde und zu dessen Standardisierungsgremium Oracle zählt.  Ein REST Gateway nimmt Anfragen entgegen, authentisiert sie gegen einen Member Service Provider und leitet sie weiter an die Peers zur Ausführung des Chaincodes. Im Chaincode werden Datenobjekte in einer Zustands-Datenbank verwaltet. Das ist eine key-value pair Datenbank wie LevelDB oder CouchDB. Ändert sich der Zustand von Objekten durch eine Transaktion, wird diese Änderung in der Blockchain mitprotokolliert. Dazu wird vorher zwischen den Peers ein Einverständnis bzw. Konsens hergestellt. Dieser erfolgt zur Zeit über einen Ordering Service, der die Reihenfolgen der Datenblöcke festlegt. Weitere Konsens-Algorithmen wie der „practical byzantine fault tolerance algorithm“ sind geplant. Eine integrierte Certificate Authority (CA) erzeugt Signaturen, die den Datenblöcken angehängt werden. Im der Oracle Blockchain unterliegenden Hyperledger Fabric Framework wird Chaincode in der Skriptsprache „Go“ formuliert. Eine Unterstützung für Java ist vorgesehen. Die  Kommunikation der Peers des Blockchain Cloud Service ist über das Apache Kafka Framework für einen hochperformanten Nachrichtenaustausch geregelt. Damit ist es auch möglich Kommunikationskanäle (als "Channel" bezeichnet) einzurichten, in welchen nur Daten zwischen einzelnen festzulegenden Parteien abgelegt werden. Jeder Kommunikationskanal erhält seine eigene Blockchain als Protokollinstanz. Jede Komponente des Cloud Service steckt in einem eigenen Docker Container für leichte Verteilbarkeit und Skapierbarkeit in der Oracle Cloud, aber auch zur Verteilung on-premise und in anderen Clouds..           Den Service nutzen Ist der neue Blockchain Service einmal eingerichtet lassen sich beispielhafte Chaincodes aus der Hyperledger Fabric in den Oracle Blockchain Cloud Service installieren und über das REST Gateway, zum Beispiel mittels gängiger REST Werkzeuge wie Postman oder dem Kommandozeilen-Tool curl, testen. Weiterführende Tests würden dann diesen Gateway Service an bestehende Anwendungen, die man um eine Blockchain-Protokollierung und deren Abfrage bzw. Verifizierung erweitern möchte, anbinden.  Und fertig ist die eigene technische Blockchain-Implementierung – lediglich der fachliche Use Case und damit der Chaincode dahinter ist noch zu definieren. Wobei diese Aufgaben zur Hauptsache werden, ist doch dank des Oracle Blockchain Cloud Service die dahinterliegende Technik ganz leicht einzusetzen.   Weitere Informationen Whitepaper Oracle Autonomous Blockchain Cloud Service  

Beitrag von Marcel Boermann, Oracle Architect for Cloud & IT Technologies, ORACLE Deutschland B.V. & Co. KG   Interessante neue Technologien wie die sogenannten Blockchains sind inzwischen herangereift...

Core Tec & Cloud Technologies Deutschland

Erstellung einer 12c Datenbank in der Oracle Cloud Infrastructure - in vier Schritten zum Erfolg

Einleitung Der folgende Artikel beschreibt das Erstellen einer Oracle 12c Datenbank in der Oracle Cloud. In vier Schritten sind sie in der Lage auf die Datenbank zuzugreifen, doch zuerst einige Gründe, die Oracle-Datenbank in unserer Cloud zu betreiben.  Die Erstellung hat ein hohes Maß an Automation – Sie sparen Zeit Die Datenbank wir nach Oracle Best-Practices erstellt - Minimierung von Konfigurationsfehler Die Infrastruktur entspricht dem heutigen Best-of-Breed - Optimales Preis/Leistungs-Verhältnis-Verhältnis Oracle auf Oracle ist die optimale Kombination - Sicherheit  Die Umgebungen können nach Ihren Anforderungen wachsen und schrumpfen - Kosteneffizienz Die Erstellung der Datenbank erfolgt in vier Schritten, genauer sind es nur drei, wenn man die Vorbereitung nicht mit einbezieht… 1. Vorbereitung – Um die restlichen drei Schritte möglichst ohne Unterbrechung durchführen zu können, müssen einige Vorbereitungen getroffen werden. 2. Erstellen eines Compartments – Die Administrations-Domain, in der die Datenbank später läuft. 3. Erstellen eines Virtual Cloud Networks – Für mehr Sicherheit und gezielte Netzwerkzugriffe. 4. Erstellen der Oracle 12c Datenbank in der Cloud – Bereitstellung der Datenbank mit den gewünschten Parametern. Jeder dieser Schritte erklärt das Vorgehen und gibt Hintergrundinformationen, Tipps und Tricks zur optimalen Durchführung. Schritt 1 - Vorbereitung Sofern Sie noch keinen Oracle Cloud Demo-Account haben, können Sie hier einen beantragen. Der Demo-Account umfasst ein Guthaben von 300 $, die Sie dafür verwenden können, verschiedene Services auszuprobieren. Wenn die 300 $ verbraucht sind, wird der Account automatisch inaktiv geschaltet und Ihnen entstehen keine weiteren Kosten. Wenn Sie den Account kostenpflichtig weiterverwenden wollen, müssen Sie dies explizit auswählen und bestätigen. Der nachfolgende Artikel beschreibt die Erstellung einer Datenbank in der Oracle Cloud Infrastructure. Um später auf die von Ihnen erzeugte Bare-Metal-Cloud-Instanz zugreifen zu können, benötigen Sie ein persönliches Private-/Public-SSH-Schlüssel-Paar. Dies dient Ihrer Sicherheit und ermöglicht nur den Besitzer des Private Keys den Zugriff auf die erstellte Instanz. Für den Zugriff per SSH gibt es keine Benutzername-Passwort-Kombination. Die Erstellung des Private-/Public-SSH-Schlüssel-Paares erfolgt mit „Bordmitteln“ der jeweiligen Betriebssysteme mit den folgenden Kommandos: Windows Für Windows verwenden Sie idealerweise Putty (www.putty.org). Putty ist ein freies MS-Windows-Toolset für die Steuerung von Linux-/Unix-basierten Systemen mit MS Windows. Auf der Kommandozeile geben Sie bitte folgenden Befehl in einem Terminal-Fenster ein: Öffnen Sie das Programm puttygen.exe Nutzen Sie die Default-Werte und geben Sie als Schlüsselgröße 2048 an. Dies bedeutet, dass der Schlüssel eine Länge von 2048 Bit aufweisen soll. Klicken Sie „Generate“ Bewegen Sie die Maus in dem freien Feld, um Zufallsdaten zu generieren Im nächsten Schritt sehen Sie im Feld "Public key for pasting into OpenSSH authorized_keys file" Ihren erstellten Public-Key-Schlüssel Anschließend sichern Sie den Public- und Private-Key Linux/Unix/Mac Auf der Kommandozeile geben Sie bitte folgenden Befehl in einem Terminal-Fenster ein: ssh-keygen -t rsa -N "" -b 2048 -C "<Ihr Name für den Schlüssel>" -f <Pfad/Name_fuer_die_Dateien> Sie können auch in einem Terminal Fenster den Befehl: ssh-keygen eingeben und anschließend die obigen Werte in den Kommando-Prompt eingeben. Die beiden Schlüssel liegen anschließend im angegebenen bzw. aktuellen Pfad. Der Schlüssel ohne Dateiendung ist der Private Key, der mit der Dateiendung „.pub“ ist der Public Key. Der Public Key wird auf dem Server gespeichert, der Private Key bleibt in Ihrem Besitz. Vorsicht: Geben Sie den Private Key unter keinen Umständen an Dritte weiter! Der Private Key ermöglicht den Zugriff auf die von Ihnen erstellten Bare-Metal-Cloud-Service-Instanz! Weiterhin bewahren Sie den Private Key sorgsam auf, wenn er verloren geht, können Sie nicht mehr auf die erstellte DB-Instanz zugreifen… Schritt 2 - Erstellen eines Compartments Ein Compartment ist eine Verwaltungseinheit in der Oracle Cloud Infrastructure, es dient dazu Ressourcen zu bündeln und diese durch spezielle Gruppen zu administrieren. Dies dient der Sicherheit, da nur berechtigte Personen die Ressourcen administrieren können, und es dient der Übersichtlichkeit, da man alle zugeordneten Ressourcen in seinen Compartments wiederfindet. Um ein Compartment zu erstellen, loggen Sie sich auf die Oracle Cloud Infrastructure ein und öffnen Sie im Menü oben links den Punkt „Identity -> Compartment“, anschließend vergeben Sie einen Namen und ggf. eine kurze Beschreibung, im letzten Schritt klicken Sie „Create Compartment“. Bild 1: Dialog zum Erstellen eines Compartments Das Erstellen des Compartments dauert ein paar Sekunden, anschließend können Sie Benutzergruppen dem Compartment zuordnen. Schritt 3 - Erstellen eines Virtual Cloud Networks In einer Cloud-Umgebung sollten die Netze der verschiedenen Kunden voneinander getrennt sein. Um dies möglichst sicher und effizient umzusetzen verwendet man ein sogenanntes „Virtual Cloud Network“, kurz VCN. Jede Ressource in der Oracle Cloud Infrastructure ist einem VCN zugeordnet, in jedem VCN können sie eines oder mehrere Subnetze erstellen, um den Netzwerkverkehr entsprechend zu kapseln. Dies erhöht die Sicherheit, da Zugriffe aus anderen Subnetzen oder VCNs gesteuert werden können. Jedes VNC hat eigene Firewall-Regeln inklusive White-/Black-Listings. Bei der Erstellung eines VCN gibt es zwei Methoden: a.) Die schnelle Methode zum Testen. b.) Die detaillierte Methode zum Aufsetzten von Produktionsumgebungen. In dieser Variante wird im ersten Schritt der Name des VCN festgelegt, anschließend können alle anderen Einstellungen, wie zum Beispiel zusätzliche Subnetze, Firewall-Regeln etc. manuell eingetragen werden. In unserem Fall verwenden wir die schnelle Methode, hier brauchen Sie nur den Namen einzugeben und das VCN wird automatisch mit drei Subnetzen erstellt. Um ein VCN zu erstellen klicken Sie in der Homepage der Oracle Cloud Infrastructure oben rechts auf Network und wählen dort Virtual Cloud Network aus. In dem darauf erscheinen Dialog vergeben Sie einen Namen und wählen den Radio-Button „CREATE VIRTUAL CLOUD NETWORK PLUS RELATED RESSOURCES“, anschließend scrollen Sie den Dialog nach unten und drücken „CREATE“. Nach kurzer Zeit steht in das Virtual Cloud Network zur Verfügung. Bild 2: Dialog - Erstellen eines Virtual Cloud Netzwerks Sie können ein oder mehrere Virtual Cloud Netzwerke erstellen und so zum Beispiel Ihre Netzwerkarchitekturen in der Cloud abbilden. Schritt 4 - Erstellen der Oracle 12c Datenbank in der Cloud Nach diesen einfachen Schritten können Sie nun die Datenbank erstellen. Die Oracle-Datenbank wird bei der Erstellung automatisch neu installiert, Oracle verwendet keine Images oder Snapshots zur Erstellung. Der Vorteil ist die Sicherheit, dass die verwendete Datenbank den aktuellsten Patch-Set hat und alle Konfigurationen und Einstellungen Ihrer Kontrolle unterliegen. Der Nachteil ist die Zeit, die es braucht, bis die Datenbank verfügbar ist, da auch das Datenbank-File-System neu erstellt wird, kann der gesamte Prozess etwas länger dauern. Unabhängig von der gewünschten Datenbankinstallation, ob Single-Instance oder Real Application Cluster, es steht immer die volle HA-Infrastruktur zur Verfügung, d. h.: Automatic Storage Management (ASM) Real Application Cluster Virtual IP Addresses (VIPs) Single Client Access Name (SCANs) Data Guard Oracle Notification Service (ONS) werden bei jeder Erstellung einer Datenbank mitkonfiguriert. Die Datenbank gibt es in drei verschiedenen Ausführungen: Als Virtual Image – d. h. die Datenbank wird in auf virtualisierten Linux-Guest-OS und Storage installiert Als Bare Metal – bei dieser Methode wird ein vollständiger physikalischer Server und lokaler Storage verwendet Als Exadata Cloud Service – hier wird eine Exadata in der Cloud verwendet Als Datenbank-Editionen werden die Standard Edition, Enterprise Edition, Enterprise Edition High Performance und Enterprise Edition Extreme Performance angeboten. Diese Versionen unterscheiden sich, außer die Standard Edition, von der On-Premise-Variante, da die Optionen nicht einzeln angeboten werden, sondern als Bundle. Die Datenbank kann bis zum heutigen Datum als Single Instance und Real Application Cluster angelegt werden, Standby Datenbank soll demnächst verfügbar sein. Um die Datenbank zu erstellen klicken Sie im oberen, rechten Menü auf den Punkt „Database“ und wählen „Launch DB System“. Im anschließenden Dialog wird eine Reihe von Eingaben verlangt, die ich im Nachfolgenden erkläre: Display Name – Dies ist der Anzeige Name des Datenbank-Systems es hat nichts mit der SID zu tun, sondern ist nur ein von Ihnen vergebener Name. Availability Domain – Jede Region (zum Beispiel Frankfurt am Main) ist in drei unabhängige Verfügbarkeitsbereiche/Rechenzentren unterteilt, wählen sie eine der Availaiblity Domains in der Sie die Datenbank erstellen wollen. Shape – Ein Shape ist die Datenbank-Ausführung und die Größe. BM steht für Bare Metal und entspricht der Datenbank-Ausführung 2 (siehe oben im Text), VM steht für Virtual Machine und Exadata für Exadata. Die Beschreibung nach der Datenbank-Ausführung stellt die Größe dar, so steht DenseIO für 28,8 TByte lokalen Storage und HighIO für 12,8 TB. RAC hat 24 TByte lokal Storage und Standard beschreibt die Verwendung von magnetischer, virtualisierter Storage gewünschter Größe. Bei Exadata wird zwischen Quarter, Half und Full Rack unterschieden. Die letzten Zahlen in der Beschreibung geben die Anzahl der Oracle CPUs/OCPUs (also Cores) an. So hat die BM.DenseIO.36 immer 36 Cores da es ja einen ganzen Server entspricht. Die Virtualisierten Shapes gibt es mit den OCPU-Anzahlen 1, 2, 4, 8 und 16. Bei dieser Variante kann man den Storage aus einer Reihe von festen Storage-Größen auswählen, der minimale Storage beträgt 256 GByte, der maximale 40960 GByte. Bild 3: Auswahl der gewünschten Datenbank-Shapes Total Node Count – Je nach verwendeten Shape wird hier die Anzahl der gewünschten Datenbank-Knoten angegeben. Oracle Database Software Edition – Je nachdem welche Anforderungen Sie haben, können sie zwischen einer Standard Edition oder einer Enterprise Edition Extreme Performance wählen. Wenn Sie sich informieren wollen, welche Datenbank-Optionen in welcher Software Edition enthalten ist, können Sie sich hier informieren (ungefähr auf der Mitte der Webseite). Available Storage Size – Geben Sie an, wieviel Storage Ihr Datenbank-System bekommen soll, dieser Wert ist rein auf die Datenmenge bezogen und nicht auf die Installationsdateien. License Type – Hier wird zwischen License Included und Bring-Your-Own-License unterschieden. Bei License Included sind alle DB-Lizenzen und der Support enthalten, bei Bring-Your-Own-License können Sie eigene on-Premise-Oracle-DB-Lizenzen in die Cloud transferieren. Bild 4: Eingabe der Datenbank-Parameter SSH Public Key – Bei diesem Punkt müssen Sie Ihren in der Vorbereitung erzeugten Public-Key in die Cloud hochladen, dabei handelt es sich um die Datei mit der Endung „*.pub“. Sie können die Datei entweder per Browser hochladen oder einfach per Drag&Drop in das „Drop SSH Key files here…“-Fenster fallen lassen. Nach den Datenbank-System-Informationen wählen Sie im gleichen Fenster die Netzwerkinformationen aus. Virtual Cloud Network – Hier wählen Sie das in Punkt 3 erstellte virtuelle Cloud-Netzwerk aus Client Subnet – Bei der Erstellung des Virtual Cloud Netzwerkes wurden per Default drei Subnetze erzeugt, jedes dieser Subnetze liegt in einer anderen Availability-Domain. Wählen Sie an dieser Stelle das Subnetz, das in Ihrer Availability Domain liegt (siehe Auswahl oben). Hostname Präfix – Oracle baut den Domänen-Namen und die Domänen-URL aus den fest vorgegebenen Teil und einem von Ihnen frei gewählten Präfix. Dieses Präfix sollte möglichst kurzgehalten werden. Hintergrund: Die Domänen-Namen sind für alle Komponenten der Oracle Cloud Infrastructure gleich lang, da für zum Beispiel Docker-Container eine bestimmte Länge des Namens nicht überschritten werden darf, gilt hier eine maximale Länge. Nach den Netzwerkinformationen kommen Sie jetzt zu den Datenbank-Informationen Database Name – Der Datenbankname Ihrer Oracle Datenbank Database Version – Die Version der gewünschten Datenbank. Aktuell haben sie die Auswahl zwischen 11.2, 12.1 und 12.2. Wählen Sie eine 12c Datenbank Ihrer Wahl! Die 12c Datenbanken werden immer als Multi-Tenant-Datenbanken angelegt. PDB Name – Name der Plugable Database, diese Angabe ist optional. Database Admin Password – Hier geben Sie das Standardpasswort für Ihre Datenbankadministratoren an, bitte beachten Sie an dieser Stelle die Passwortrichtlinien. Wenn Ihr eingegebenes Passwort den Richtlinien entspricht, wird der Text unter dem Eingabefeld grün angezeigt. Bild 5: Eingabe der Datenbank-Informationen Nach Bestätigung der Eingaben wird die Datenbank erstellt. Wichtige Informationen: Wie in dem Artikel bereits erwähnt, wird für jede neue Datenbank eine komplette Grid-Infrastruktur bereitgestellt (ASM etc.), das heißt die Bereitstellung der Datenbank benötigt eine gewisse Zeit. Die DBAs unter Ihnen werden es aus persönlicher Erfahrung verstehen, als Nicht-DBA werden Sie eher ungeduldig werden. Sie können mehrere Datenbankinstanzen pro System anlegen, das ist zum Beispiel wichtig zu wissen, wenn Sie mit der Standard Edition von Oracle arbeiten, die ja nicht auf 36 OCPUs in einer Bare Metal Instanz bereitgestellt werden kann. Die Datenbanken sind per Default verschlüsselt. Es wird automatisch ein Autologin Wallet erstellt, damit Sie sich ohne Probleme direkt an die Instanz anmelden können. Das Virtual Cloud Network hat bei der Erstellung eine automatische Security-List, per Default ist ausschließlich der SSH Port (22) freigeschaltet, alle anderen Inbound-Verbindungen werden automatisch geblockt. Wenn Sie zum Beispiel auf Port 1521 aus dem Internet zugreifen wollen, müssen Sie diesen erst in den Security-List-Einstellungen freischalten. Jedes erstellte Datenbank-System hat auf der Betriebsystem-Ebene eine eigene Firewall, beachten Sie bitte, dass auch hier ggf. Ports freigeschaltet werden müssen. Der Parameter cpu_count ist per Default auf 4 gestellt, wenn Sie größere Instanzen erzeugen, vergessen Sie bitte nicht den Parameter zu vergrößern. Die Parameter db_block_checking und db_block_checksum sind auf FULL gestellt, berücksichtigen Sie es bei Performance-Vergleichen und reduzieren Sie es bei Bedarf. Zugriff auf die Datenbank-Instanz Wenn die Datenbank erstellt wurde, ändert sich das Datenbank-Image von orange auf grün. Die Sicherheitseinstellungen der Firewall des Datenbank-Images sind per Default so eingestellt, dass alle Ports außer dem SSH-Port geschlossen sind. Das bedeutet die erste Verbindung auf die Instanz erfolgt per SSH. Um diese Verbindung herzustellen benötigen sie den Private-Key, den Sie in den Vorbereitungen erstellt haben. Die SSH-Verbindung kann per PUTTY (Windows) oder Terminal-Fenster (Linux/Unix/Mac) erfolgen. Die Kommandozeile für die Verbindung per Terminal lautet: ssh -i ./pfad/private_key_file opc@öffentliche_IP_Adresse_der_DB_Instanz Im ersten Teil des Befehls geben Sie den Pfad und Dateinamen zum Private Key an, der Private Key ist die Datei ohne Endung. Als nächstes müssen Sie den Benutzer des Cloud Images angeben, dieser Nutzername ist „opc“ und steht für Oracle Public Cloud. Als letztes müssen Sie nach dem @ die öffentliche IP-Adresse der Datenbank-Instanz angeben, diese findet sich in den Detail-Informationen der Datenbank. Fazit Durch die neuen deutschen Oracle Rechenzentren in der Region Frankfurt bekommt das Oracle Cloud Angebot einen ganz neuen Stellenwert. Durch die Datenhaltung in Deutschland ermöglichen wir unseren Kunden die Einhaltung einer Vielzahl von lokalen, deutschen Richtlinien und ermöglichen den Zugriff auf die Daten mit geringer Latenz und größerer Bandbreite. Das Erstellen einer Oracle Datenbank ist im Vergleich zu einer Installation On-Premise wesentlich einfacher und schneller. Mit minimaler Parameter-Eingabe kann eine lauffähige Instanz in kurzer Zeit erstellt werden. Dieses kleine Tutorial sollte Ihnen aufzeigen, wie einfach es ist. Natürlich können Sie weitaus speziellere Konfigurationen mit dem Oracle Database Cloud Service umsetzen, dies ist jedoch nicht das Ziel des Tutorials. Weitere Informationen zum Thema Oracle Cloud finden Sie auf der Webseite http://cloud.oracle.com  

Einleitung Der folgende Artikel beschreibt das Erstellen einer Oracle 12c Datenbank in der Oracle Cloud. In vier Schritten sind sie in der Lage auf die Datenbank zuzugreifen, doch zuerst einige Gründe,...

IaaSundPaaS

Identity Cloud Service: SSO und Benutzerverwaltung in der Cloud

Oracle bietet mit dem Oracle Identity Cloud Service eine Umsetzung eines generischen Services zur Verwaltung von Accounts, Berechtigungen, Single-Sign-On und Reporting. Der Service lässt sich mit einen OnPremise Identity System koppeln, was dann ein hybrides Identity Management (siehe Gartner) ermöglicht. Die Koppelung reicht von einfachen Synchronisationen, über Beantragungen und Workflows bis hin zur (Re-) Zertifizierung der Berechtigungen. Ein Single-Sign-On vom lokalen System, z.B. der Windows Anmeldung, ist möglich. Für den Endbenutzer ist dabei transparent wo sich das System befindet. Die Hauptfunktionen lassen sich in vier Gruppen zusammenfassen. Umsetzung von Standards Identity Management Anmeldung, Authorisierung und Single-Sign-On Hybrides Identity Management OpenID Connect, OAuth, SAML, SPML Mittels UI, Rest-Services oder Synchronisation Führende oder nachgelagerte Anmeldung und Single Sign On, Rollen Koppelung über Workflows (OIM), oder Rest-Services, Synchronisation mit AD Aussagekräftiger als Funktionen sind die verschiedenen Möglichkeiten zur Nutzung: Integration von SaaS oder cloudbasierten Services Im Zuge der Nutzung von cloudbasierten Services können diese in das zentrale Anmeldeverfahren integriert werden. So ist an einer Stelle steuerbar wer sich anmelden kann. Kontextsensitivität kann dabei je nach Service genutzt werden. Der Benutzer kann sich so über sein Single-Sign-On an diese Services anmelden. Dabei kann man auf einen „Katalog“ mit vorgefertigten Integrationen (ca 80 Stück) zurückgreifen oder Integrationen basierend auf einem der unterstützten Standards (OAuth/OpenIDConnect, SAML, FormFill) erstellen. Anmeldung / Single Sign On - auch für Eigenentwicklungen Verschiedene Verfahren zur Integration von Anwendungen und Services stehen zur Verfügung. Entweder per Standard wie SAML oder OpenID Connect oder Eigenentwicklungen basierend auf einem der o.a. Standardprotokolle bzw. der vorhandenen Rest-API Mit SAML können z.B. das lokale AD über ADFS oder Services, neben Oracle SaaS, Office 365, Salesforce etc. angeschlossen werden. Über die genannten Standards können starke Authentifizierung (OTP, TOTP) und künftig auch Social Logins genutzt werden Hybrides IAM: Koexistenz bzw. Integration mit bestehenden IAM Systemen Bestehende IAM Systeme können über verschiedene Mechanismen angebunden werden, die von Synchronisation (z.B. AD) über Workflows (z.B. OIM) bis zur direkten Verwendung der Schnittstellen reichen. Das daraus entstehende hybride IAM System kann die weiterführenden Funktionen des jeweiligen anderen Systems nutzen. Z.B. die Rezertifizeirung von Accounts oder das Antragswesen durch das OnPremise System Der Endbenutzer bekommt ein Single-Sign-On dass von seiner Desktopanmeldung oder von seinem Corporate Login aus gestartet wird. Cloudmodell: Einfach und skalierbar Für den Zugang spielt es keine Rolle, ob ein Benutzer innerhalb des Unternehmensnetzwerks kommt oder über das Internet Sofortige Nutzungsmöglichkeit nach Konfiguration Nachweisbarkeit durch entsprechende Reports bzw. Reportingdaten Scale-up für die Nutzung von bzw. durch Millionen von Nutzern Der Oracle Identity Services beinhaltet die Erfahrungen von Oracle mit den eigenen Cloud Services und über 17 Millionen verwalteten Benutzern und Mandanten. Die unterliegende Micro-Services Architektur ermöglicht ein sanftes service-seitiges Nachrüsten von Funktionen wie z.B. kontextbasierte Authentifizierung. Führende Analysten bewerten Funktionsumfang und Nutzbarkeit positiv. Beispielsweise bewertet Gartner 2017 die Access und Governance Funktionen von Oracle beide Male mit der Positionierung im „Leader Quadrant“. Weitere Informationen zu Anwendungsfällen im Folgeartikel. Zusammenfassung und Ausblick Oracle Identity Cloud Service (IDCS) stellt eine cloudbasierte IAM Plattform zur Verfügung. Damit können sowohl Mitarbeiter, Externe, Partner, Kunden und Dinge (z.B. Geräte oder IoT) verwaltet und angebunden werden. Durch vorgefertigte Integrationen, sowohl bzgl. der Anbindung von OnPremise IDM Systemen als auch SSO Systemen ist eine einfache Nutzung möglich. Für den Benutzer ist der Service Dank SSO transparent. Oracle selbst hat diesen Service in seine neuen Oracle Public Cloud Services (OPC) eingebunden und die bestehenden OPC werden auf diese Plattform migriert. Ein mit OPC bestehender IDCS Service kann, je nach Lizenz, dann auch für andere Dinge genutzt werden. Hier geht's zum Service und der Dokumentation: https://cloud.oracle.com/en_US/identity.

Oracle bietet mit dem Oracle Identity Cloud Service eine Umsetzung eines generischen Services zur Verwaltung von Accounts, Berechtigungen, Single-Sign-On und Reporting. Der Service lässt sich mit...

Sicherheit

Identity und Accessmanagement OnPremise

Identity und Access Management im Portfolio von Oracle hat drei Säulen: Governance, Access und Directory. Im Folgenden finden Sie eine kurze Aufstellung der in den Säulen enthaltenen Komponenten bzw. Funktionen:   Identity Governance: Oracle Identity Manager (OIM) ist die Komponente für das Provisionieren von Benutzern, Accounts und Berechtigungen. OIM liefert dabei u.a. Self-Services, Beantragungen, delegierte Administration, (periodische) Berechtigungsprüfungen, Genehmigungsworkflows und Berechtigungsmanagement über die angeschlossenen bzw. verwalteten Systeme. OIM kennt die Berechtigungen in den Systemen und ermöglicht damit Berichte, (periodische) Berechtigungsprüfungen und die Untersuchung von Berechtigungsverletzungen. Kritische Berechtigungsprüfungen (englisch SoD) können hinterlegt werden. Dashboards liefern die jeweilige Managementsicht. Role Mining wird durch die Komponente Oracle Identity Analytics (OIA) zur Verfügung gestellt. Oracle Privileged Account Manager (OPAM) ermöglicht eine dedizierte Verwaltung von kritischen bzw. privilegierten Accounts, so dass auch nachweisbar ist wer wann welche Accounts zur Nutzung (via CheckOut) freigeschaltet bekommen hatte.   Access Management: Oracle Access Manager (OAM) ist eine webbasierte Single Sign On Lösung für Authentifizierung und Autorisierung, die auch mit Millionen von Usern skaliert kann. Durch die verwendeten Standards werden auch stark heterogenen Umgebungen unterstützt. Hierbei trägt die zentrale Steuerung der auf den dezentralen Webserver geltenden Zugriffsrichtlinien zur effizienten Verwaltung bei. Die relevanten Federation Standards wie SAML oder OAuth werden unterstützt. Zusammen mit Oracle Secure Token Service (STS) ist es ein Multi-Protokoll Federation Server, der sich in ihre Access Lösung mit der Bereitstellung von weiteren Protokollen integriert und so „Cross-Domain“ User Zugriff ermöglicht. Oracle Adaptive Access Manager (OAAM) stellt eine risikobasierte Zugriffskontrolle inkl. forensischer Auswertung bei Zugriffsversuchen. Zusätzlich werden Authentifizierungsmechanismen wie Einmal-Password für SMS, interaktive Sprachauthentifizierung, via E-Mail und via Instant Messaging zur Verfügung gestellt.. Oracle Entitlement Server (OES) bietet das standardbasierte Auslagern von Berechtigungen und Policies für Anwendungen und Webservices eines Unternehmens (Stichwort XACML) . So können feinstgranualare Berechtigungen modelliert und zentral bereitgestellt werden. Oracle Enterprise Single Sign-On (OeSSO) Plus stellt ein sogenanntes Desktop Single Sign On zur Verfügung, das häufig dann genutzt, wird wenn sich eine Applikationen nicht über einen SSO Standardmechnismus (vgl. Access Manager) integrieren lässt. Beispielsweise Mainframe Applikationen über Terminalemulationen. Oracle Access Portal ermöglicht einem Benutzer sich sein Single Sign On Portal zu konfigurieren. Durch die Integration der gängigen Protokolle wie SAML, OAuth als auch konventionellem User/Passwort können dann mit einer einzigen Anmeldung nahtlos die anderen Systeme, unternehmenseigen oder nicht, genutzt werden. Oracle Mobile and Social Services erweitern die SSO Mechanismen in Richtung mobiler Clients (Browser und Applikationen/Apps ) und können die Sicherheit abhängig des genutzten Gerätes steuern. Darüber hinaus können in die SSO Lösung soziale Netzwerke wie Facebook, Google, Yahoo, Twitter und LinkedIn hinsichtlich deren Logins und Identitäten integriert werden, so dass der Benutzer einen nahtlosen Übergang in Unternehmensapplikationen ohne erneute Registrierung oder Anmeldung hat.   Directory Services: Oracle Unified Directory (OUD) und Oracle Directory Services Enterprise Edition (ODSEE) stellen jeweils hoch skalierbare LDAP Directory Services auf Basis der Berkley DB Technologien. Oracle Virtual Directory (OVD) bietet eine einheitliche LDAP Sicht auf bzw. Virtualisierung der  Daten die in LDAP Verzeichnissen und SQL Datenbanken liegen. Oracle Internet Directory (OID) ist  ein LDAP Directory Service auf Basis der Oracle Datenbank Technologie.   Weiterführende Informationen finden Sie im Internet unter http://www.oracle.com/security.

Identity und Access Management im Portfolio von Oracle hat drei Säulen: Governance, Access und Directory. Im Folgenden finden Sie eine kurze Aufstellung der in den Säulen enthaltenen Komponenten bzw....

IaaSundPaaS

Identity Cloud Service Use Cases

Die folgenden Anwendungsfälle sind Beispiele zur Nutzung des Services. Diese lassen sich selbstverständlich untereinander koppeln. Hybrides Management von Benutzern In diesem Fall können Benutzer sowohl OnPremise verwaltet werden als auch in dem entsprechenden Cloud Service: Die Vorteile dieser Koppelung sind: Benutzer die im OnPremise System gepflegt werden sind automatisch im cloudbasierten Identity System vorhanden und können so die „nur“ an das cloudbasierte IAM System angeschlossene Applikationen ebenfalls nutzen. Die Nutzung ermöglicht neben dem SSO, dass im nächsten Abschnitt beschrieben wird, bis hin zur Beantragung von cloudbasierten Systemen (wie bspw. SaaS Services). Aus Sicht der Verantwortlichen ergibt sich eine holistische Sicht auf alle Accounts und Berechtigungen. Das sind Anforderungen aus dem Bereich der Regularien. Benutzer die nicht im OnPremise System gepflegt werden, wie bspw. Kunden oder Bewerber etc. werden nur im cloudbasierten System gepflegt. Das vereinfacht das Sizing einer bestehenden OnPremise Lösung. Über delegierte Administration können auch Mandanten abgebildet werden. Nahtloser Zugriff auf (Oracle) Public Cloud Applications Der Identity Cloud Service bietet die Möglichkeit verschiedene Cloud Services über ein SSO zu integrieren. Eine manuelle Konfiguration über SAML oder OAuth ist grundsätzlich möglich, für einige Oracle Cloud Services und einige Applikationen wie beispielsweise Salesforce ist eine Vorkonfiguration vorhanden.   Vorteil dieser Koppelung ist, dass nur ein SSO zum OnPremise System konfiguriert werden muss, alle weiteren Systeme werden an den IDCS angeschlossen.   Identity und Access für Eigenentwicklungen und/oder auslagern des Benutzermanagements IDCS kann verwendet werden, um den Anteil an der Entwicklung für IAM Services (Anmeldemöglichkeit, SSO, Benutzerpflege) zu reduzieren. Neben den aufgeführten Funktionen sind Self-Services zum Management der Profildaten, Zurücksetzen des Passworts etc. vorhanden. Verantwortliche verfügen zusätzlich über delegierte Administration und Reporting Funktionen.   Um Benutzern die Nutzung von Anwendungen (z.B. Firmenwebportal) oder Apps (z.B. Fitness App) zu ermöglichen, müssen diese erfasst und gemangt werden. Je nach Daten muss auch die Einwilligung der Benutzer dabei berücksichtigt werden (sogenannter User Consent). Damit wird diese Funktion in beiden Fällen als Service genutzt und ist von der Entwicklung und Weiterentwicklung der Eigenentwicklungen getrennt. Die Skalierung funktioniert transparent anhand der Anzahl der Nutzer, es ist keine Verwaltung von Instanzen notwendig.  

Die folgenden Anwendungsfälle sind Beispiele zur Nutzung des Services. Diese lassen sich selbstverständlich untereinander koppeln. Hybrides Management von Benutzern In diesem Fall können Benutzer sowohl...

IaaSundPaaS

Cloud Security Services

Es gibt dedizierte Cloud Security Services, die keine Add-Ons zu bestehenden Cloud Services sind, sondern Services, die eigenständig genutzt werden können. Eine Integration einer Benutzerverwaltung und eines Monitoring kann damit auch für 3rd Party Clouds vorgenommen werden. Es handelt sich um folgende Cloud Security Services: Oracle Identity Cloud Service (IDCS) stellt eine cloudbasierte Identity und Access Management (IAM) Plattform zur Verfügung. Damit können sowohl Mitarbeiter, Externe, Partner, Kunden und Dinge (zum Beispiel Geräte oder IoT) verwaltet und angebunden werden. Durch vorgefertigte Integrationen, sowohl bezüglich der Anbindung von On-Premise IDM Systemen als auch SSO Systemen ist eine einfache Nutzung möglich. Für den Benutzer ist der Service durch SSO transparent. Oracle selbst hat diesen Service in seine neuen Oracle Public Cloud Services (OPC) eingebunden und die bestehenden OPC werden auf diese Plattform migriert. Ein mit OPC bestehender IDCS Service kann, je nach Lizenz, dann auch für andere Aufgaben genutzt werden. Mehr >>> Tests mit dem Identity Cloud Service sowie weitere Informationen und Dokumentation unter https://cloud.oracle.com/en_US/identity. Der Service ist in den Oracle Rechenzentren in den USA und für EMEA in Amsterdam verfügbar Mit dem Cloud Access Security Broker (CASB) kann die Nutzung der Cloud Services überwacht werden, um einerseits eine Schatten-IT zu entdecken, und um andererseits die Cloud Nutzung bzgl. Missbrauch/Angriffen zu monitoren. Gängige Services wie Salesforce, Office365 oder AWS sind vorintegriert. CASB nutzt ein Identity Management System, zum Beispiel den IDCS, um Rückschlüsse auf den eingeloggten Benutzer ziehen zu können und im Rahmen des Vorfalls entsprechende Vorschläge anzubieten (zum Beispiel Deaktivieren des Accounts im IDCS oder Rücksetzen der Konfiguration in einem Account). Mehr >>> Direkt zum Service und zur Dokumentation: https://cloud.oracle.com/en_US/casb Cloud Security Monitoring und Compliance Services sollen zur Überwachung verdächtiger Operationen in Cloud und On-Premise Umgebungen eingesetzt werden. Hierbei ist meist der vermeintlich genutzte Account und dessen Berechtigungen oder die Berechtigungshistorie von Interesse. Compliance wird bezüglich der Konfiguration der Services überwacht, z.B. Datenbanken sind immer verschlüsselt. Diese Services sind für 2017 geplant. Weitere Informationen zu: Security Monitoring https://cloud.oracle.com/en_US/security-analytics Compliance bezüglich Konfigurationen: https://cloud.oracle.com/en_US/compliance Mit CASB und den Monitoring Services können in einem Security Operations Center (SOC) die Cloud Umgebungen überwacht bzw. Richtlinien zur sicheren Konfiguration umgesetzt werden. Diese Services können natürlich auch als Input für ein bestehendes Security Information und Event Management (SIEM) System genutzt werden.

Es gibt dedizierte Cloud Security Services, die keine Add-Ons zu bestehenden Cloud Services sind, sondern Services, die eigenständig genutzt werden können. Eine Integration einer...

Sicherheit

Monitoring der Cloud mit dem Cloud Access Security Broker

Mehr als jedes zweite deutsche Unternehmen nutzt heute schon Angebote aus der Cloud. Und die Cloud Nutzung wird, z.B. laut Cisco Global Cloud Index, kontinuierlich weiter steigen. Mit dem steigenden Nutzungsgrad und damit einhergehend weiteren cloudbasierten Services benötigen Unternehmen in diesen Bereichen ausgeklügelte Werkzeuge zur Absicherung und Einhaltung von Richtlinien bzw. Compliancevorgaben. Bereits im Juni 2016 hat Gartner festgestellt dass eine oder die wichtigste Security Technologie dazu die sogenannten Cloud Access Security Brokers (im Folgenden CASB) sein werden. Die Nutzung von CASBs ist über die Jahre kontinuierlich angestiegen. Laut Prognosen von Analysten werden bis 2020 85% der großen Unternehmen CASBs einsetzen. Der  “2016 Insider Threat Spotlight Report” bestätigt auch das Momentum für CASB Lösungen, wonach 74% der befragten Unternehmen Insider Angriffe als Problem sehen aber weniger als die Hälfte davon ausreichende Massnahmen umgesetzt haben. Ein CASB deckt im Prinzip zwei Anwendungsfälle ab: Entdecken einer Schatten-IT in der Cloud die von Einzelnen oder Abteilungen aufgesetzt wurde Die Überwachung der Unternehmensvorgaben bezüglich Nutzung von Cloud Diensten inkl. dem Einhalten sicherheitsrelevanter Konfigurationen CASBs werden dabei standalone oder als Teil einer Securitylösung (z.B. SIEM) eingesetzt. Sie arbeiten entweder innerhalb des Zugriffsweges (Proxy) oder über eine API Integration. Der Oracle Cloud Security Access Broker bietet diese Funktionalitäten und Einsatzmöglichkeiten. Durch die API basierte Architektur erfordert er keine gesonderte Komponente im Netzwerk. Viele Standardintegrationen in Cloud Services als auch in Firewalls bzw. Gateways ermöglichen eine hohe Grundabdeckung. Standardintegrationen bestehen für die Cloud Services von Amazon AWS, Azure Office 365, AzureAD, Box, GitHub, Google Apps, Rackspace, Salesforce, ServiceNow, Slack und Oracle Public Cloud (HCM, ERP, Sales Cloud). Zur Auflösung der Benutzer Benutzern bzw. deren Identitäten können die Repositories IDCS, Okta und Ping angebunden werden. Die Entdeckung der SchattenIT erfolgt über die Einbindung der  Firewalls bzw. Gateways von Sophos UTM, Checkpoint Syslog, Fortigate, Palo Alto, Bluecoat und Checkpoint SmartView Tracker. Mit dem Einsatz des CASB wird eine holistische Überwachung der Konfiguration und Nutzung der Cloud ermöglicht, ohne in die Infrastruktur eingreifen zu müssen. Oracle Cloud Access Broker: Überblick Der Oracle Cloud Access Broker automatisiert die Analyse der Nutzung von Cloud Services und reduziert damit dramatisch den Aufwand. Die Vorgehensweise entspricht dem aus der Forensik: 1. Aggregation der Daten von verschiedenen Cloudprovidern 2. Analyse der aggregierten Daten gegen bekannte Threads und Suche von Mustern bzw. Abweichungen und Extrahieren von möglichen Incidents 3. Priorisieren in Empfehlungen, die im Anschluss ausgeführt werden können 4. Remediation bzw. Durchführung der Aktionen Diese Steuerung erfolgt über ein Dashboard. Nachfolgend ein Beispiel mit verschiedenen Analysen (Geo Regionen der Zugriffe, riskante Accounts, Zugriffsarten, Findings und offenen Aktionen). In jedem der Bereiche ist ein Drill Down möglich, wenn nötig bis auf das SQL Statement. Oracle Cloud Access Broker läuft vollständig in der Cloud und benötigt „keine“ Einbindung  in das Netzwerk. Die Integration erfolgt auf Basis von APIs und Filetransfers. Dies ermöglicht einen minimal invasiven Aufbau. Als Cloudservice nutzen sie dabei zu jedem Zeitpunkt nur die Ressourcen (Nutzer, Systeme, Daten) die Sie aktuell benötigen. Ein wichtiger Aspekt ist die hohe Automatisierung. Bei neu bekannt gewordenen Vorfällen, neuen Services, weiteren Nutzern, etc. neue Regeln zu definieren, zu testen und zu tracken ist extrem aufwendig. Daher setzt der Cloud Access Broker hier ein „Machine Learning“ ein. Dieses Machine Learning erkennt Muster in der Nutzung die vom Standard abweicht. Dazu wird eine „Baseline“ ihrer Nutzer und der Vergleichsgruppe erstellt und verglichen. In den Der Vergleich beinhaltet zeitliche Aspekte sowie eine Historienbetrachtung Beides zusammen wird auch „User Behaved Analytics (UBA)“ genannt. Abweichungen sind typischerweise Kandidaten für Missbrauch von Accounts durch einen legitimen Benutzer (z.B. Nutzung eines Cloud Angebot für eigene Daten), Missbrauch des Accounts durch einen Insider (z.B. über Service Acounts der Cloud) oder kompromitierte Accounts (gehackt, erraten oder gestohlen). Laut „Verizion Data Breach Report“ ist der grösste Anteil von Vorfällen auf Probleme mit Accounts zurückzuführen, daher liefert der Blick aus Sicht der Accounts auf die Cloud Services Mehrwerte. Die gefundenen Fälle werden zur Analyse auf dem Dashboard dargestellt um diese weiterzuverfolgen. Sie können Einzelaktionen auf den Accounts ausführen oder Tickets zur Weiterverarbeitung erstellen. Eine andere Funktionalität, die Überwachung von Konfigurationen dient der Sicherstellung Unternehmensvorgaben nicht (mit Vorsatz) zu unterlaufen, wie Abschalten einer starken Authentifizierung oder unverschlüsselte sensitive Daten. Beispiel: Beim Data Breach im Juli 2017 waren mehrere Millionen Kundendatensätze inkl. Account PINs, Namen, Telefonnummern zugreifbar. Durch eine Fehlkonfiguration eines Administrators waren die Daten in einem Amazon S3 Bucket für jeden beliebigen AWS Nutzer zugreifbar. Neben den grundsätzlichen Schutzmechanismen wie Verschlüsselung und Zugriffsbeschränkung die, wenn auch fehlerhaft, konfiguriert waren, hätte hier Oracle Cloud Access Broker (CASB) wie folgt helfen können: CASB überwacht in AWS die Konfiguration bei sensiblen S3 Buckets. Hier hätte man entdeckt, dass der Zugriff für jeden AWS Nutzer, auch anderer Mandanten, möglich wird.  Hier hätte man schon einschreiten können. CASB fände auch nachträglich geänderte Konfigurationseinstellungen. CASB entdeckt den Abruf von Daten. Hier würde bei sensiblen Daten, die von „unbekannten“ Nutzern abgerufen werden, ein entsprechender Alarm erzeugt Aktionen zur Behandlung können entsprechend automatisiert werden, Benachrichtigung des Helpdesks, Deaktivieren von Accounts, Ändern von Zugriffsberechtigungen. Zusammenfassung und Ausblick Oracle Cloud Access Broker (CASB) stellt eine cloudbasierte Plattform zur Überwachung cloudbasierter Dienste zur Verfügung. Um Rückschlüsse auf den Benutzer hinter den Aktionen ziehen zu können bindet CASB ein Identity Verzeichnis an. Aktionen, wie Deaktivierung von Accounts oder Rücksetzen von Konfigurationen können hinterlegt werden. CASB kann natürlich auch in (bestehende) SIEM Systeme und Cloud Security Monitoring Services als Quelle integriert werden. CASB bietet die Basis für Identity Security Operations. Positive Rezensionen sind unter dem alten Produktnamen Palerra zu finden bzw. als Oracle CASB 2017 von den Analysten von VDC Research. Weitere Informationen Tests mit dem Oracle Cloud Access Broker sowie weitere Informationen und Dokumentation unter https://cloud.oracle.com/en_US/casb Weiterführende Informationen zu Security & Oracle finden Sie im Internet unter http://www.oracle.com/security Übersicht zum Oracle Cloud Access Broker als pdf zum download

Mehr als jedes zweite deutsche Unternehmen nutzt heute schon Angebote aus der Cloud. Und die Cloud Nutzung wird, z.B. laut Cisco Global Cloud Index, kontinuierlich weiter steigen. Mit dem steigenden...

CloudDev

DevOps und Oracle

Dieser Artikel führt in das Thema DevOps ein und zeigt auf wie DevOps von Oracle unterstützt wird und gibt einen Ausblick auf die möglichen Plattformen für die so erzeugten Anwendungen und Services. Der Begriff DevOps bildet sich aus den Wörtern Development und Operations und beschreibt einen Ansatz, den Prozess der Softwareentwicklung und IT Systemadministration zu verbessern.  DevOps ist also mehr als Philosophie und Methodik zu verstehen, als eine konkrete Lösung. Es gibt auch nicht nur eine richtige DevOps Umsetzung oder Implementierung für die Geschäftsabläufe zur Entwicklung und zum Betrieb von Software. Es werden vielmehr Eckpfeiler oder Phasen definiert,  die dann methodisch unter Zuhilfenahme von Tools und Software behandelt werden. Was sind die Eckpfeiler für DevOps? Alle wesentlichen Aufgaben in der Softwareentwicklung, der Bereitstellung und der Verwaltung  des Betriebes  lassen sich in einem kleinen Schaubild  wie folgt darstellen. Diese Themenbereiche findet man mehr oder weniger vollständig in allen Softwareprojekten immer wieder vor. Daher kann man eine solche Verallgemeinerung als quasi Blueprint vornehmen, ohne den Anspruch zu erheben, dass alle Phasen immer durchlaufen werden oder das man erst bei vollständiger Existenz  aller Phasen von DevOps spricht. Für gewöhnlich beginnt man mit der Planungsphase  für eine Softwareentwicklung. Im Normalfall steigt man nach Abschluss der Entwicklung und der Phase des Betriebes und des Monitorings wieder in die Planungsphase für Verbesserungen und neue Releases ein. Die hier genannten Phasen werden also im Normalfall mehrfach iterativ durchlaufen, so dass DevOps den gesamten Software Lebenslauf  begleitet. Was bringt dieses Vorgehen? Zunächst einmal bringt eine DevOps Planung Klarheit über alle wichtigen Aufgabenbereiche im Software Lebenszyklus und ermöglicht ein strukturiertes Vorgehen aller Beteiligten. Das sorgt wiederum für eine klare fachübergreifende Aufgabendefinition ein schnelleres Ausrichten auf Geschäftsanforderungen eine Reduzierung von Fehlerquellen schon in der Planung eine bessere Planung der benötigten Ressourcen bzgl. Qualität und Quantität uvm. Durch Summe aller Vorteile kann man schließlich viel Mühen und vor allem Kosten sparen. Welche Rolle spielt Cloud Computing für DevOps? Zunächst einmal sind DevOps und Cloud Computing unterschiedliche und voneinander unabhängige IT Disziplinen. Die steigende Bedeutung von Cloud Computing in der Unternehmens IT ist einerseits eine direkte Antwort auf die heutzutage enorme Geschwindigkeit, mit der Disruptionen das Business der Unternehmen beeinflussen und andererseits Ausdruck für eine Phase des Übergangs von einer produktorientierten hin zu einer serviceorientierten Ökonomie. Menschen messen immer mehr dem Erlebnis eine Bedeutung bei als dem eigentlichen Produkt, während Unternehmen immer noch vermehrt Produkte herstellen, die sie dann in Services verpacken. Die Geschäftstransition in der Automobilbranche ist der beste Beleg dafür. Die Bezeichnung Produkt beschränkt sich jedoch nicht nur auf hergestellte Gegenstände, wie ein Fahrzeug, sondern auch auf immaterielle Dinge, wie Software. Auch hier ist ein Wandel vom Besitzen einer Software oder –lizenz hin zu einer Orientierung auf die Nutzung zu verzeichnen. Software as a product wird zu Software as a Service. Hersteller von materiellen Produkten werden auch immer mehr zu Softwareherstellern, weil Software mittlerweile alle Lebensbereiche durchdringt - kein Auto fährt heute mehr ohne Software, Smart Devices sind auf dem Vormarsch. Das hohe Maß an erforderlicher Flexibilität und Agilität macht vor der Entwicklung und in dem Betrieb der Softwarelösung nicht Halt.  Auch bei der Umsetzung von DevOps Methoden und Prozessschritten werden in der IT Tools und Lösungen benötigt, die den gleichen Anforderungen wie das Kerngeschäft der Unternehmen unterliegen. Time to market und Kostenoptimierung sind allgegenwärtige Eckpfeiler und Fundament für die Wettbewerbsfähigkeit von Unternehmen. Cloud Computing und DevOps bilden also gemeinsam eine strategische Einheit. Was ist Oracles Beitrag zu DevOps? Für jede Phase des Softwarelebenszyklus biete Oracle Cloud basierte Lösungen und Toolsets an. Herzstück ist der Developer Cloud Service, der alle wesentlichen Toolsets und Lösungskomponenten für die Phasen der Softwareentwicklung und -bereitstellung als Service anbietet, wie z.B. Issue Tracking Agiles Projektmanagement Wikis Git Repositories für die Source Code Verwaltung inkl. IDE Anbindung, Code Review, Code Entwicklungstool in der Cloud Unterstützung populärer Build Frameworks, wie Maven, Grunt, Gradle, Gulp, Hudson, uvm Orchestrierung und Abhängigkeitsmanagement Test Plattform (JUnit, Selenium, FindBugs ,…)  Paketierung und direktes Deployment, z.B. in die PaaS Umgebungen Java Cloud Service (Java EE), Application  Container Cloud Service (JavaSE, NodeJS, PHP, Ruby, Python), Container Cloud Service (Docker Container), Mobile Cloud Service (Mobile Services) Die jeweiligen Oracle PaaS Dienste, bswp. Java Cloud Service, Application Container Cloud Service u.a.,  bedienen dann jeder für sich die entsprechenden DevOps Phasen nach dem Deployment, wie z.B. Operation:  Scale out / Scale up, One Click Upgrades & Patching der Laufzeitumgebungen usw. Bezüglich des Monitorings empfiehlt es sich, den Oracle Management Cloud Service als dedizierten Verwaltungsdienst einzusetzen. Hierüber werden alle Anforderungen an Verwaltung und Monitoring im Softwarebetrieb abgebildet. Alle Bereiche von DevOps werden in einer abgestimmten  Symbiose von Tools und Lösungen von Oracle als Platform as  Service abgedeckt. Fazit DevOps ist in der heutigen Welt der hoch dynamischen und omnipräsenten Softwaredurchdringung ein Weg, den Softwarelebenszyklus optimal zu gestalten. Cloud Computing spielt hierbei eine immer wichtigere Rolle, um die nötige Flexibilität und Agilität beim Einsatz von Tools und Laufzeitplattformen zu gewährleisten und die Kosten im Griff zu halten, was eine wesentliche Grundlage für die Wettbewerbsfähigkeit von Unternehmen bildet. Oracle liefert für alle DevOps Bereiche die entsprechenden Lösungen als Cloud Service an. Überzeugen Sie sich selbst und schauen Sie auf http://cloud.oracle.com für weitere Informationen.   Autor: Detlef Müller, ORACLE Deutschland B.V. & Co. KG

Dieser Artikel führt in das Thema DevOps ein und zeigt auf wie DevOps von Oracle unterstützt wird und gibt einen Ausblick auf die möglichen Plattformen für die so erzeugten Anwendungen und Services. Der...

CloudDev

Mobile Computing mit der Cloud

Mobile Computing ist insbesondere für die IT Organisation von größeren Unternehmen eine echte Herausforderung. Der Bedarf der Fachbereiche und die damit verbunden Anforderungen an mobilen Lösungen wachsen laut einer Gartner Studie  5x schneller als die Kapazitäten von IT Organisationen abdecken können. Diese Diskrepanz betrifft in erster Linie die Agilität in der Entwicklung („Time To Market“) und die Dynamik bei Pflege und Wartung der implementierten Lösungen. Zudem wird es immer schwieriger und vor allem teurer, gute Entwickler anzuheuern um die Kapazitäten entsprechend auzustocken. Gartner resümiert: “Organizations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic” Adrian Leow, Principal Research Analyst Die Website Information Age sekundiert hier und stellt fest, dass man zwar ein klares Verständnis des Nutzens von mobilen Lösungen hat, aber oft nach einem Ad Hoc Ansatz statt einer Strategie gesucht wird. Die Plattformsuche definiert dabei oft erst die mobile Strategie. Selbst wenn 7% der befragten Unternehmen eine Strategie implementiert haben, nutzen wenige Mehrwertdienste wie App Reporting und Nutzungsanalysen. Bei 1/3 aller befragten Senior IT Managern wurden Sicherheitsbedenken als wesentliche Probleme genannt, gleich gefolgt von Kosten und Komplexität (ebenfalls 1/3). Eine Backend Integration in der Cloud wird als nächste drückende Herausforderung formuliert. Es besteht ein allgemeiner Konsens dass: Der Aufbau von Enterprise Apps mindesten 6 Monate dauert Eine Integration von Legacy Systemen zu komplex ist man die hohe Dynamik in den App Frameworks schlecht bewältigen kann Enterprise Apps immer datenzentrisch sind und auf den Endgeräten hohe Datenlasten bedin­gen Eine Integration von Unternehmenssoftware in mobile Anwendungen ist mit klassischen SOA Infra­strukturen schlicht nicht zu bewältigen, weil mobile Endgeräte und deren Anwendungskonzept ein eigenes Anforderungsprofil aufweisen. Das fängt oft schon bei der Bereitstellung der notwendigen APIs an. SOAP Services, wie sie von unternehmens­weiten Integrationsarchitekturen auf Basis eines Service Bus meist verwendet werden, sind für mobile Welten ungeeignet. In mobilen Anwendungen haben sich REST / JSON Dienste durchgesetzt. Um eine befriedigende App Performance zu ermöglichen, muss jegliches Parsen, Filtern oder Transformieren von zum Teil großen Datenpaketen aus der mobilen Anwendung herausgehalten werden. Eine zusätzliche Transformation oder gar ein Redesing des API Ökosystems würde einen erheblichen Mehraufwand für die Service Entwickler bedeuten. Es gibt zudem Besonderheiten in einer mobilen Anwendung, die für die Ausgestaltung der Integration relevant sein und den Service Entwickler herausfordern können, wie z.B. Offline Synchronisation, Verbindungsstabilität (Datendurchsatz, Latenzen usw.), etc. Die Lösung dieser Probleme trägt einen Namen: Mobile Backend as a Service (MBaaS), von Oracle mit der Bezeichnung Mobile Cloud Service angeboten. Hier wird eine für mobile Belange spezifische Integrationsebene als Clouddienst eingesetzt, die das Bindeglied zwischen den Service Designern und dem App Entwickler darstellt. Durch die Abstraktion der Zugriffe auf das IT Ökosystem des Unternehmens kann man bereits einige Anforderungen nach Absicherung der Zugriffe auf Unternehmens APIs abbilden. Natürlich löst das nicht alle Sicherheitsbedenken bzgl. mobiler Anwendung, insbesondere wenn Daten auf den Endge­räten gespeichert sind. Hierfür muss ein gesamtheitliches Sicherheitskonzept erstellt werden, wel­ches mit weiteren Diensten umgesetzt wird. Auch dafür bietet Oracle entsprechende Service an. Der Fokus in diesem Blog liegt aber auf der Erleichterung der Integration über ein MBaaS - der Oracle Mobile Cloud. Eine Mobile Cloud ist der Hort aller für den App Entwickler notwendigen Services als Set von APIs. Diese beinhalten einerseits die Repräsentation der Unternehmens Backend Services als sogenannte Custom APIs als auch zugehöriger Plattform Mehrwertdienste (Platform APIs). Eine solche Plattform API beinhaltet bspw. das Versenden von Push Notifications. Dies ist eine Be­sonderheit von mobilen Anwendungslösungen, die von herkömmlichen SOA Integrationslösungen nicht abgedeckt wird. Wenn ein Unternehmens Backend z.B. aus einer Prozess Asynchronität heraus eine Nachricht zum Anwender proaktiv schicken möchte (Nachricht außerhalb der Anwendung auf den Sperrbildschirm bzw. Notifcation Bereich), dann müssen die Messaging Services der entspre­chenden Plattformbetreiber, wie Google, Apple, Microsoft, Blackberry, usw. aufgefordert werden, die Nachricht an das Endgerät auszuliefern. Dazu muss man aber auf Ebene des Unternehmensba­ckend wissen, welche Plattform App Registratur zu welchem User und zu welcher Plattform gehört. Neben der eigentlichen Ansprache der Messagingdienste (APIs) zur Übermittlung der Notification muss man also ein Verwaltungssystem für die App Registratur definieren und pflegen - es sei denn man bekommt diese Funktion wie bei der Oracle Mobile Cloud komplett als Plattform Dienst bereit­gestellt. Um Aussagen über das tatsächliche Nutzungsprofil der App zu treffen und etwaige Optimierungspo­tenziale zu identifizieren, wollen die zuständigen Fachbereiche oft zusätzliche Informationen erhal­ten. Im Normalfall kann man nur durch die über die mobile App erstellten oder veränderten Daten und Inhalte auf dem Unternehmensbackend entspreche Schlüsse ziehen, also z.B. Anzahl der Auf­tragseingänge, der abgearbeiteten Service Requests etc. Vielleicht lässt sich auch noch die Anzahl der Installationen auf den Endgeräten ermitteln, nicht aber was auf den mobilen Geräten in der App ge­schieht, ohne dass die Aktionen sich in den Backenddaten widerspiegeln. Da der Mobile Cloud Ser­vices das Backend der mobilen Anwendung ist und alle Daten und Dienste liefert, lassen sich weiter­führende Diagnose- und Analysefunktionen hier platzieren. Fachanwender können bei Bedarf Einsichten über die Nutzung der App gewinnen und Antworten zu fachlichen Fragen erhalten. Beispielsweise sind das: Von welchem Standort aus wurden Anfragen an die Mobile Cloud gesendet? Wie viele Benutzer sind pro Tag aktiv, wie viele davon sind neu? Wie ist der zeitliche Verlauf der aktiven oder neuen Benutzer pro Tag über einen bestimmten Zeitraum, auch über die betreffenden Apps gefiltert?  „Funneling“ Informationen, also wann wurden Bearbeitungsschritte in der App wie oft und an welcher Stelle abgebrochen. … Der App Entwickler kann Sensoren oder „Collectors“ in seiner Anwendung einbauen und reicht darüber die Daten an die Analytics API der Cloud weiter. Dort erfolgt dann die Auswertung für den Fachanwender. Auch die Behandlung von Offline Funktionen wird bereits über die Mobile Cloud Plattform bereitge­stellt und muss nicht vom Service Entwickler auf Unternehmensseite abgebildet werden. Der Appentwickler muss natürlich die lokale Datenbehandlung implementieren, greift dafür aber nicht auf das Unternehmensbackend zu sondern auf entsprechende Plattform API der Mobile Cloud. Von dort wird dann die Kommunikation mit dem Unternehmens Backend organisiert. In der Regel muss man in der Anwendung eine Authentifizierung vornehmen, um Zugriffe auf Daten und Funktionen abzusichern und Personalisierungen jeglicher Form abbilden zu können. Im mobilen Umfeld haben sich Token basierte Authentifizierung mit OAuth durchgesetzt. Hier bietet der Mobile Cloud Service einen Dienst an, gegen den sich die Anwendung authentifizieren lässt. Auf der Mobile Cloud sorgt dann ein Dispatcher dafür, dass die Authentifizierungsanforderung auf den eigentlichen Security Provider weitergeleitet wird. Dies kann auch ein Social Media Provider, wie Facebook sein. Über eine Connector Architektur können auch weitere Identity Propagation Dienste, bspw. SAP, Right Now, Oracle Fusion Apps usw. angebunden werden. Die Mobile Cloud stellt viele Mehrwertdienste für den App Entwickler, die nicht erst durch den Service Entwickler entwickelt werden müssen. Das vereinfacht den Aufbau einer mobilen Lösung enorm und spart viel Zeit und Kosten. Neben den technischen Aspekten der Implementierung einer mobilen Lösung liegt der Vorteil einer Cloud basierten Architektur in der nutzungsbezogenen Kostenberechnung. In der Regel haben Projekte ein Gesamtbudget, die Kostenstrukturen verschieben sich aber im Laufe der Projektrealisierung. Zu Projektbeginn liegt der höhere Kostenanteil bei der initialen Bereitstellung der Infrastruktur und den initialen Implementierungsaufwänden, ohne dass irgendjemand einen Nutzen aus der Lösung ziehen kann. Später, wenn die Lösung zu funktionieren beginnt und die ersten Tests anlaufen oder die ersten Benutzer aktiv sind, vielleicht auch sogar schon erste Kostenrückflüsse durch die Wirkung der Lösung entstehen, verlagern sich die Kostenproportionen weg von der Bereit­stellung und Entwicklung hin zu Betriebsaufgaben. Eine nutzungsbezogene Berechnung der Infra­strukturkosten wie im Cloud Modell dient also der Minimierung der initialen Projektkosten und senkt die Risiken für den Unternehmer. Fazit Eine Mobile Cloud ist ein Mobile Backend as a Service, welches eine Integrationsplattfom für mobile Anwendungen darstellt und die Welt der Unternehmensanwendungen mit der mobilen Welt schnell und effektiv verbindet. Neben den Integrationsaufgaben stellt die Mobile Cloud auch Mehrwert­dienste bereit, die einerseits den Aufbau einer mobilen Plattform extrem beschleunigen („Time to Market“) und andererseits die Kosten für die Integration minimieren können. Oracle Mobile Cloud ist ein geeigneter Lösungsbaustein für die Probleme der Implementierung einer unternehmensweite Mobile Strategie. Autor: Detlef Müller, ORACLE Deutschland B.V. & Co. KG

Mobile Computing ist insbesondere für die IT Organisation von größeren Unternehmen eine echte Herausforderung. Der Bedarf der Fachbereiche und die damit verbunden Anforderungen an mobilen Lösungen...

CloudDev

Application Development in der Cloud

Application Development bei Oracle wird oft mit Datenbank Entwicklung auf der Basis APEX oder natives PL/SQL in Verbindung gebracht. Das ist nachvollziehbar und in gewisser Weise auch richtig, da Oracle anerkanntermaßen der bedeutendste Datenbank Software Hersteller ist und eine sehr große Kundenbasis, also auch Entwicklergemeinde, aufweist. Eine Reduzierung der Technologien für Anwendungsentwicklung auf diesen Bereich ist jedoch falsch, da Oracle schon seit sehr langer Zeit Anbieter von Geschäftsanwendungen sowie der Fusion Middleware als Technologieplattform ist und dadurch naturgemäß weitere Entwicklungstechnologien, wie z.B. Java, JSF, Java Script usw., im Fokus liegen. Durch die Akquise von Sun im Jahre 2010 hat Oracle auch die Federführung in der Weiter­entwicklung von Java übernommen. Darüber hinaus spielen insbesondere im Zeitalter von Microser­vices Architekturen noch andere Entwicklungsparadigmen, -technologien und –konzepte eine bedeu­tende Rolle – auch für Oracle. Die Firma RedMonk als Analyst für Entwicklerthemen führt regelmäßig Auswertungen der Nutzungsgrade von Frameworks bzw.  Programmiersprachen durch und erstellt auf Basis der Aktivitäten auf GitHub und Stack Overflow ein Ranking (Siehe http://redmonk.com/sogrady/2016/07/20/language-rankings-6-16/). In dem Maße, wie PL/SQL auf GitHub oder Stack Overflow nicht oder kaum vertreten ist, wird es auch in diesem Ranking kaum be­achtet. Die genannten Repositories sind keine typischen Tools für PL/SQL oder APEX Entwickler, da die Entwicklungsmethodologien hierfür sich meist unterscheiden. Demnach ist diese Studie nicht repräsentativ, zeigt aber wichtige Trends im non-Database Entwicklungsumfeld auf. Dieser Artikel ist ein Auftakt für eine Serie von weiteren Veröffentlichungen über nicht klassische Datenbank oder SQL Themen. Im Zeitalter von PaaS vermischen sich die IT Dis­zipli­nen Datenbank und Middleware ohnehin immer stärker und gesamtheitliche Technologie- und Archi­tekturbetrachtungen rücken in den Fokus. Gerade für Anwendungsentwickler ist eine Cloud-basierte Infrastruktur von großem Nutzen, da eine hohe Flexibilität und Dynamik, insbesondere für Bereitstellung von Plattformen zur Projektentwicklung Testen und Qualitätsabnahme Verwaltung der Entwicklungsarbeiten (Development Operations = DevOps) benötigt werden, bei gleichzeitiger Minimierung der initialen Kosten hierfür. Eine Virtualisierung der Entwickler-Infrastruktur hat sich bereits seit langem durchgesetzt. Jedoch müssen die Entwickler immer noch die VM Abbilder erstellen und verwalten, die entsprechende Hardware sowie die gülti­gen Lizenzen der eingesetzten Produkte beschaffen bzw. sicherstellen. Wie schön wäre es, wenn man alles zugleich bei Projektstart dynamisch verprovisioniert bekommt – und zwar auch nur für die Dauer des Projektes. Das funktioniert nur mit einem Cloud-basierten Lösungsansatz. Oracle bietet für Entwickler eine Cloud-basierte App Dev Plattform Suite, in der mehrere  PaaS Dienste lose gebündelt werden. Für die Bereitstellung der Anwendung in Laufzeitumgebungen kann der Entwickler zwischen verschiedenen Optionen an Container Diensten wählen. Der Application Container Cloud Service bietet vorkonfektionierten Docker Containern mit Node.js, Java SE bzw. PHP Runtimes an. Weitere vorkonfektionierte Runtime Container sind in Kürze für diesen Clouddienst zu erwarten. Kurzum, der Application Container Cloud Service ist für alle Anwendungen da, die eine Java Virtual Machine (JVM) benötigen. Möchte der Entwickler seine Anwendungen in einem eigenen Docker Container bereitstellen, so nutzt er dafür den generi­schen Container Cloud Service. Schließ­lich kann auch für größere Java EE Anwendun­gen der Java Cloud Service herangezogen werden. Hierbei wird ein Weblogic Server als Cloud Dienst verprovisioniert und der Entwickler hat Zugriff auf die komplette WLS Domain inkl. der Administrati­onstools in der Cloud, um seine Anwendungen dort zu deployen und zu konfigu­rieren. Zu guter Letzt kann der Entwickler auch einen  Compute Service beziehen, wenn er spezielle Anforderun­gen für die Bereitstellung seiner Anwendung zu erfüllen hat und lediglich eine Compute Ressource für seine Arbeiten benötigt. Der Vorteil der Oracle Cloud Services besteht nicht nur in der flexiblen und dynamischen Bereitstel­lung der entsprechenden Ressourcen, sondern auch der dafür notwendigen Verwaltungsebene in grafischen Weboberflächen. Das vereinfacht das Konfigurationsmanagement (Instanzen erstellen, Ressourcen Pools anlegen, private Registraturen defineren usw.), das eigentliche Deployment („1-Click Deployment“), die Orchestrierung von Containern (gerade bei einer Microservice Architektur) und nicht zuletzt  auch das operative Management der Umgebungen. Natürlich unterliegt die Anwendungentwicklung einem Lebenszyklus – von der eigentlichen Ent­wicklung der Codebase, über das Zusammenbauen der Einzelteile zu einer Anwendung (Build), die Paketierung der Anwendung bis hin zur deren Bereitstellung (Deployment). Hierfür bietet Oracle den Developer Cloud Service an. Dies ist eine Plattform für agiles Entwickeln mit einem entsprechen­den Continuous Integration Toolset, d.h. Code Repository, Build Management, Testing Tools usw., bis hin zur Unterstützung der kollaborativen Arbeitsaufgaben, wenn man in Teams entwickelt (Scrum/Agile, Wikis, Issue Tracking). Ein Wesensmerkmal des Developer Cloud Service ist seine Offenheit und die Basis auf etablierten Standardwerkzeugen. Oracle hat also das Rad nicht neu erfunden, sondern die bestehenden Tools in einer Plattform gebündelt. Um diese Plattform aus den jeweiligen Entwicklungswerkzeugen (IDEs) anzusprechen und von dort aus Code Artefakte z.B. ein- bzw. auszuchecken usw., gibt es entsprechende Plugins für Eclipse, Netbeans und JDeveloper – also die am häufigsten eingesetzten Entwicklungswerkzeuge. Aus der Developer Cloud können dann schließlich auch die Deployments in die angeschlossenen Cloud Dienste für die jeweiligen Laufzeit­umgebungen direkt angestoßen werden. Neben der Neuentwicklung von Anwendungen mit Hilfe der und für die Oracle Cloud ist auch das Thema Modernisierung von bestehenden Implementierungen ebenso wichtig und steht auf der Agenda der IT Verantwortlichen und Entwickler. Auch hierfür bietet Oracles Application Develop­ment Platform Suite einen Nutzen und trägt zur kosteneffizienten Modernisierung bei. Im Prinzip geht es hier um die Transformation der Workload von On-Premise Systemen in die Cloud mit Anforderungen, wie Migration existierender Workloads ohne Änderungen Automatisierung von Entwicklungsarbeiten mit DevOps Application Performance Monitoring und Diagnose Automatisierung des fortlaufenden Managements / Lifecycle der Systeme Erweiterung mit Microservices Modernisierung mit Mobile und modernem Web UX Der Mehrwert liegt in der Automatisierung vieler Arbeiten und der Reduktion von Maintenance Kos­ten (Ba­ckup, Patching, Hardware / Firmware / OS Upgrades, …), Softwarekosten (Lizenzen, Installa­tion, Kon­figuration, …), Hardware Kosten  (insbesondere bei Skalierungen) und Facility Kosten. Fol­gendes Bild visualisiert das Transformationskonzept bestehender Java / Datenbanklösung in die Cloud. Für die Transformation stehen entsprechende Toolsets zur Verfügung. Fazit Für Aufgaben der Anwendungsentwicklung eignet sich ein Cloud –basierter Ansatz besonders, da in hohem Maße die für Entwickler erforderliche Flexibilität und Dynamik in der Bereitstellung der Lauf­zeitumgebungen gewährleistet ist bei einem, im Vergleich zu herkömmlichen Infrastrukturen, relativ geringen Kostenaufwand. Oracle stellt mit der Application Developer Platform Suite eine Vielzahl von verschiedenen PaaS Lösungen für die Belange der Entwickler zusammen - von Laufzeitcontainern auf Docker Basis bis hin zu komplexeren Application Server Runtimes im Java Cloud Service. DevOps Tooling werden ebenso über eine Developer Cloud bereitgestellt, so dass die Entwicklung in Teams sowie die Verwaltung der Artefakte, das Zusammenbauen der Anwendungen und deren Bereitstel­lung in den Cloud Runtimes mit Standard Toolings unterstützt wird. Schließlich bieten sich die Oracle Cloud Dienste für eine Vielzahl von Modernisierungsaufgaben für bestehende Anwendungslösungen an. Diese reichen von Änderungen des Betriebskonzeptes ohne Anpassungen der Anwendungsim­plementierung bis hin zu Erweiterungen mit modernen Diensten. In allen Fällen werden Kosten für Betrieb und Pflegen & Wartung der Infrastruktur von Oracle kostengünstig übernommen. Autor: Detlef Müller, ORACLE Deutschland B.V. & Co. KG

Application Development bei Oracle wird oft mit Datenbank Entwicklung auf der Basis APEX oder natives PL/SQL in Verbindung gebracht. Das ist nachvollziehbar und in gewisser Weise auch richtig, da...

IaaSundPaaS

Überblick IaaS und PaaS Services

Oracle bietet im Bereich Cloud Services das umfassendste Portfolio für Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS), Software as a Service (SaaS) und Data as a Service (DaaS) an. Im Folgenden werden IaaS und SaaS weiter betrachtet. Sie bezeichnen verschiedene Gruppen von Services die sich hinsichtlichder Verantwortlichkeit des Service-Nutzers und des Service-Providers unterscheiden.    In der IaaS-Gruppe verwaltet der Service-Nutzer Infrastruktur-Ressourcen wie zum Beispiel  Compute-Knoten, Storage-Einheiten oder Netzwerke selber. Der Service-Provider verantwortet die Performance, Verfügbarkeit und Zugangsmöglichkeiten zu den genannten Ressourcen.  Informationen zu den IaaS Services: https://cloud.oracle.com/en_US/iaas Die PaaS-Gruppe bezeichnet Services auf denen der Service-Nutzer ausschließlich Zugriff auf die Plattform-Komponenten erhält. Die zentrale Idee ist, dass der Service-Nutzer sich ausschließlich auf plattformspezifische Tätigkeiten konzentriert. Die darunter liegende Infrastruktur wird vom Service-Provider administriert. Ein Beispiel ist eine Applikations-Entwicklungs-Umgebung in der ein Entwickler keinen Zugriff auf das enthaltene Betriebssystem erhält. Informationen zu den PaaS Services: https://cloud.oracle.com/en_US/paas Mittlerweile existieren eine Reihe von Mischformen, die zwischen IaaS und PaaS angesiedelt sind. Der Hintergrund dafür ist, dem Service-Nutzer die maximale Flexibilität einer IaaS-Umgebung mit einem hohen Grad der Automatisierung/Standardisierung einer PaaS-Umgebung bereit zu stellen.   Ausgehend von einem Top-Down oder einem Bottom-Up-Ansatz sind folgende Vorgehensweisen denkbar: Top-Down: Der Service-Nutzer verwendet einen SaaS-Ansatz für sein ERP-System. Der Service wird vollständig vom Service-Provider administriert wird und bildet 80 Prozent der Funktionalität ab, die der Service-Nutzer braucht. Für die verbleibenden 20 Prozent benutzt der Service-Nutzer selbst entwickelte Applikationen/Erweiterungen, die auf PaaS-Umgebungen entwickelt wurden bzw. betrieben werden. Die Applikationen benötigen evtl. Legacy Komponenten die ausschließlich auf Betriebssystem-Ebene implementiert werden, dann wird IaaS benötigt. Bottom-Up: Eine IT-Abteilung fällt die Entscheidung erste Versuche in der Cloud zu machen. Um zu schnellen Ergebnissen zu gelangen wird eine On-Premise Applikation auf der IaaS-Cloud installiert. Die Applikation läuft zufriedenstellend aber das Einsparungspotenzial ist begrenzt, da der Hauptteil der administrativen Arbeit im gleichen Umfang getätigt werden muss wie On-Premise. Im nächsten Schritt werden PaaS-Service genutzt, die durch Automatisierung und Standardisierung ein erhöhtes Einsparungspotential bieten. Aber auch in diesem Fall bleibt der großer Kostenfaktor im Bereich Entwicklung und Applikations-Verwaltung. Im nächsten Schritt können bestimmte Dienste als SaaS genutzt werden, Voraussetzung ist hoher Abdeckungsgrad der benötigten Funktionalitäten. Bei SaaS erhält der Service-Nutzer das höchste Einsparungs-Potenzial, bei der geringsten Flexibilität der drei Service-Gruppen. Weiterführende Informationen sind nach einzelnen Themenbereichen aufgeteilt: Einstieg in IaaS Alle Artikel zu IaaS und PaaS    

Oracle bietet im Bereich Cloud Services das umfassendste Portfolio für Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS), Software as a Service (SaaS) und Data as a Service (DaaS)...

Datenverwaltung

Überblick Datenmanagement, Big Data und Analytics

Immer mehr Organisationen speichern, verarbeiten und generieren Mehrwert aus Daten unterschiedlichster Form und Größe. Ein breites Datenmanagement-Portfolio von Oracle kann unterschiedliche Unterstützung liefern. So kann die traditionellen Oracle Datenbank in ihrer aktuellen Version 12.2 nicht nur als einfacher Speicher für strukturierte und unstrukturierte Daten verwendet werden, sondern kann auch als Multimodell Datenbanksystem betrachtet werden. Ganz gleich in welchem Format die Daten vorliegen, die Datenbank bietet in jedem Fall eine optimierte Speicherung - ob In-Memory in einem speziellen Spaltenformat (auch Column Store), im traditionellen Hauptspeicher oder auf Platte - und das ganz automatisch mit Information Lifecycle Management sogar innerhalb der Datenbank. Mehr Informationen zu den einzelnen Themen finden sich auf folgenden OTN Seiten: Oracle Database In-Memory Oracle Advanced Compression Oracle bietet für jede Art und Größenordnung von Daten eine Lösung und unterstützt dabei die unterschiedlichsten Arbeitslasten. Dabei machte es keinen Unterschied, ob Daten OnPremise oder in der Cloud genutzt werden. Die Verwendung ist überall die Gleiche. Unstrukturierte Daten im Oracle Multimodell Datenbanksystem Ein Kennzeichen eines Multimodell Datenbanksystems ist nicht nur die Möglichkeit unterschiedliche Datenformate zu unterstützen, sondern auch spezielle Datentypen und Indizes, wie auch Datenmodelle für die Speicherung und den Zugriff von JSON und XML Dokumente zur Verfügung zu stellen. Aber auch Komponenten wie Sharded Key-Value Speicher, Property Graphen, RDF Tripel Speicher und auch die Möglichkeit Multimedia und Geospatial Informationen zu speichern und abzurufen, stellen Merkmale der Oracle Database 12c dar.  Zur Verwendung ist dabei keine zusätzliche Installation erforderlich. Fundamentale Eigenschaften der Datenbank wie Transaktionssicherheit, Transaktionskonsistenz und Rollback sind und bleiben unverändert. Auch das optimierte Zusammenspiel mit den Technologien aus dem Data Warehouse und Analytics Umfeld wie Partitionierung und Parallelisierung ist garantiert. Dabei existieren keinerlei Einschränkungen. Anwendungen auf diesen Daten profitieren von existierenden funktionsfähigen  Betriebskonzepten wie Backup und Recovery oder auch den Datenbank Security Mechanismen. Einen guten Überblicksartikel zum Thema findet sich hier. Big Data und Analytics Das enorme Wachstum von Daten, die Notwendigkeit diese zu verarbeiten, führt dazu, dass immer mehr Unternehmen sich mit dem Thema Big Data beschäftigen. Mit Big Data ist dann nicht nur eine große Datenmenge gemeint sondern auch die Art der Datenbestände, die nicht im klassischen Warehouse gespeichert werden. Klassischerweise werden solche Datenbestände in sogenannten Hadoop Clustern gespeichert. Ergänzend bietet die Oracle NoSQL Datenbank eine weitere Möglichkeit der verteilten Datenhaltung. Einen integrierten Zugang zu allen Datenquellen im Big Data Umfeld bietet Oracle Big Data SQL. Die Einbindung von Daten außerhalb der Datenbank erfolgt dabei mit der bewährten External Table Technologie, die spezifische Treiber für Daten im HDFS und HIVE zur Verfügung stellt. Eine besondere Eigenschaft von Big Data SQL ist die Nutzung der Smart Scan Technologie, die bereits seit Jahren im Exadata Umfeld erfolgreich im Einsatz ist. Diese ermöglicht durch intelligente Algorithmen eine hocheffiziente Vorfilterung der Daten direkt auf dem Speichermedium (z.B. Hadoop Cluster).  Die Analyse von Daten spielt eine wichtige Rolle um wertvolle Erkenntnisse zu gewinnen. Dies hilft dabei, Unternehmensprozesse zu bewerten und zu verbessern oder gar Prognosen (Predictive Analytics) für die Weiterentwicklung abzugeben. Bei schnell wachsenden Datenmengen und Sourcen und immer neueren Technologien stellt diese Aufgabe für viele eine Herausforderung dar - besonders auch dann wenn die Analyse unter Zeitdruck erfolgen soll. Oracle Advanced Analytics bietet performante Data-mining Algorithmen und statistische Funktionen, die sowohl von SQL und R genutzt werden können. Die Integration mit open-source R ermöglicht den Anwendern, R Scripts zu schreiben bzw. Packages zu nutzen und gleichzeitig die Vorteile der Datenbank zu nutzen. Aktuelle Erweiterungen im Oracle Advanced Analytics Release 12.2 ermöglichen sogar eine explizite semantische Analyse (ESA) basierend auf einer existierenden Wissensbasis wie beispielsweise Wikipedia. Applikationen mit Textdokumenten um beispielsweise Themenverwandtschaft herzustellen (Similarity) oder um explizites Topic Modeling durchzuführen sind typische Anwendungsfelder. Weiterführende Informationen finden sich auf folgenden OTN Seiten: Data Warehousing und Big Data  Oracle Advanced Analytics Oracle NoSQL Big Data SQL    

Immer mehr Organisationen speichern, verarbeiten und generieren Mehrwert aus Daten unterschiedlichster Form und Größe. Ein breites Datenmanagement-Portfolio von Oracle kann...

Einstieg

Überblick Security

Oracle bietet im Bereich IT Sicherheit bzw. Security vielfältige Unterstützungsmöglichkeiten für OnPremise Produkte bzw. Architekturen, in der Cloud und in hybriden Modellen. Durch die sukzessive Einführung von IT Komponenten in Unternehmen sind häufig Einzellösungen entstanden, die meist ihre eigene Security mitbringen. Die Verteilung der IT Systeme im eigenen Rechenzentrum oder der Cloud birgt weitere Herausforderungen. All dies verursacht beim Schutz und bei der Wahrung der Compliance einen hohen manuellen Aufwand. Ein zentrale Blick auf den aktuellen Stand der IT Security wird erschwert. Vorrangiges Ziel für die IT-Architektur ist, dass die Daten zuverlässig verfügbar sind (Merkmale: Ausfallsicherheit, Hochverfügbarkeit, Integrität) sowie jederzeit nur von berechtigten Personen einseh- sowie bearbeitbar sind. Weder sollen kritische Informationen aus dem Firmennetz oder der Cloud unberechtigt heraus gelangen, noch sollen Daten von Unbefugten verändert werden können. Bedrohliche Sicherheitslücken sind nicht nur von außen zu schließen, sondern auch von innen. Verschiedene Untersuchungen von "Angriffen" oder "Complianceverletzungen" zeigen, daß es auch im nachhinein nicht die eine Komponente gibt, die einen Rundumschutz gewährleistet hätte. Die Zunahme der Vorfälle bzw. deren Analyse zeigt auch, dass es nicht ausreicht den Perimeter, in der Regel die Firewall, zu verstärken. Im Rahmen der Digitalisierung beispielsweise muss es Zugriffe von aussen durch die Firewall für neue Anwendungsfälle geben. Problematische Zugriffe können aber auch von innen kommen. Neben der Zunahme einzuhaltender Regularien oder deren Konkretisierung kommt nun im Rahmen des EU Datenschutzgesetzes auch eine Auskunftspflicht hinzu. Unternehmen müssen nachweisen wie sie im einzelnen die - hier personenbezogenen - Daten schützen und welche Daten sie gespeichert haben. Oracles Ziel ist es, neben sicheren OnPremise Komponenten, sichere und vertrauenswürdige Public Cloud Infrastruktur-, Plattform- und Softwareservices (IaaS, PaaS und SaaS) zur Verfügung zu stellen. Viele Oracle Produkte sind für den traditionellen OnPremise Einsatz und für Public oder Hybrid Cloud inkl. der Sicherheitseigenschaften identisch oder kompatibel, so daß eine Migration in die Cloud nur eine andere Betriebsplattform darstellt. Durch die Unterstützung einer hybriden Architektur ist die Laufzeitumgebung des Services teilweise transparent und es können die gleichen Security Policies verwendet werden wie z.B. Verschlüsselung in der Datenbank, Gewaltentrennung oder erlaubte Loginzeiten. Spezialisierte Cloud Services wie Cloud Access Security Broker oder Identity Cloud Service ergänzen das Cloudportfolio. Soll ein Cloudmodell lokal genutzt werden besteht die Möglichkeit eine Oracle Cloud Appliance (Cloud@Customer) in Ihrem Rechenzentrum zu nutzen. Die für eine sichere Nutzung der Cloud Services notwendigen Verantwortlichkeiten werden durch umfassende dokumentierte Prozesse geregelt und fließen in die Auftragsdatenverarbeitung ein. Je nach Service liegen Zertifizierungen für Compliance Anforderungen vor oder können durch bestehende technische und organisatorische Maßnahmen von Oracle oder den Kunden abgebildet werden. Weiterführende Informationen sind nach einzelnen Themenbereichen aufgeteilt: Oracle Security Philosophie Oracle Public Cloud Security Oracle Cloud Security Services Oracle Identity und Accessmanagement (On-Premise) Alle Artikel zu Security Security Vorträge auf der OOW 2017

Oracle bietet im Bereich IT Sicherheit bzw. Security vielfältige Unterstützungsmöglichkeiten für OnPremise Produkte bzw. Architekturen, in der Cloud und in hybriden Modellen. Durch die sukzessive...

IaaSundPaaS

Überblick und Einstieg in IaaS

Die Oracle Cloud bietet zwei Arten von Infrastruktur Services, Elastisch und Dediziert. Beide Gruppen unterscheiden sich in der Exklusivität der Ressourcennutzung. Beim Elastic-Compute-Service erstellt der Nutzer seine Instanzen auf einen Shared-System. Das bedeutet er hat „Nachbarn“ auf der genutzten Hardware die ggf. Einfluss auf die Performance haben. Vorteil bei dieser Art der Infrastruktur ist die Flexibilität/Elastizität in der Auswahl der CPU/Speicher-Größen. Bei Dedicated-Compute hat der Nutzer die Umgebung exklusiv zur Verfügung, d.h. je nach Service kann der Nutzer einen vollständigen Rechnerknoten bzw. ganze Server-Schränke mieten. Der Vorteil ist eine lineare und vorhersehbare Performance die nicht durch andere Benutzer auf den gleichen System beeinflusst werden. Die nachfolgende Darstellung ist keine vollständige Auflistung aller zur Verfügung stehenden Services. Sie vermittelt eine Übersicht über das IaaS-Angebot von Oracle. Eine detaillierte und vollständige Erklärung der Services inklusive Umfang, Kosten und Dokumentation finden Sie unter cloud.oracle.com/iaas.   Elastic-Compute Beim Elastic-Compute oder auch General-Purpose-Compute kann der Nutzer zwischen verschiedenen CPU/Speicher-Varianten auswählen. Angefangen bei einen (Virtuellen) Core mit 7.5 GB RAM bis zu 16 (Virtuellen) Cores mit 120 GB RAM. Die Compute-Knoten haben Basis-Storage der mit Block-Storage erweitert werden kann. CPU, RAM und Storage sind virtualisiert.   Dedicated Compute: Zum diesem Thema existieren zur Zeit zwei Varianten: Den Bare Metal Cloud Service, hierbei erhält der Nutzer exklusiv einen Rechnerknoten. Auf diesen Knoten kann ein Betriebssystem-Image mit oder ohne Hypervisor bereitgestellt werden. Der Bare Metal Server hat lokale NVMe basierte SSD-Storage der extreme I/O-Operationen ermöglicht. Da der Nutzer exklusiv auf CPU/RAM/Storage zugreift, gibt es eine lineare Performance ohne Störungen durch ggf. andere Benutzer. Für Anwendungsfälle in denen mehr Leistung erforderlich ist bietet Oracle den Dedicated Compute Service. Der Nutzer kann bei einer Mindestabnahme von 500 (virtuellen) Cores ein exklusives System mieten. Dedicated Compute gibt es in einer X86 oder einer SPARC Architektur. Die Compute-Instanzen werden virtualisiert bereitgestellt. Durch die exklusive Nutzung entstehen keine Seiteneffekte durch andere Nutzer auf dem System.   Serviceübergreifende Komponenten In diesem Abschnitt werden Ressourcen vorgestellt, die für beide Varianten Elastic-und Dedicated Compute zur Verfügung stehen. Für eine sichere Verbindung zwischen dem Kunden-und Oracle-Rechenzentrum wird VPN verwendet. Je nach verwendeten Service wird IPSEC unterstützt. Das Virtual Private Network verschlüsselt bzw. tunnelt die gesamte Netzwerk-Kommunikation zwischen dem Nutzer-Services und dem Nutzer Rechenzentren. Wenn es auch schnell sein soll, bietet Oracle die Fast Connect Netzwerk-Option. Hier kann das Kunden-Rechenzentrum mit 1GBit bzw. 10GBit direkt an die verwendet Oracle Cloud Services angebunden werden. Vorteile sind eine hohe Bandbreite und geringe Latenzzeiten.   Mit dem Loadbalancing Service ist eine hochverfügbare, skalierbare und sichere Lösung für die Lastverteilung über verschiedene Cloud-Services in unterschiedlichen Rechenzentren möglich. Der Service unterstützt HTTP/S und TCP Protokolle und ermöglicht das Einbinden eigener SSL Server-Zertifikate (X.509).   Als günstige Storage-Lösung für zum Beispiel Archivierungen bietet Oracle Storage Cloud Services. Diese object-storage-basierende Speicher-Lösungen gibt es in verschiedenen Ausprägungen. Für das direkte Speichern von Datenbank-Backups gibt es den Oracle Database Backup Service, das Backup bzw. Recovery wird von der gewünschten Oracle Datenbank per RMAN und verschlüsselt auf die Service gesichert bzw. wiederhergestellt. Für die kostengünstige und sichere Langzeitspeicherung von großen Datenmengen bietet Oracle den Oracle Storage Cloud Service – Object Storage bzw. Archive Storage. Beide sind object-storage-basierend und unterscheiden sich in der geplanten Zugriffsfrequenz der gespeicherten Daten. Während der Storage Cloud Service – Object Storage für Daten verwendet werden die regelmäßig und in kürzeren Abständen gespeichert bzw. geladen werden, ist der Storage Cloud Service – Archive Storage auf eine Langzeit-Archivierung ausgelegt (>zwei Wochen).   Für den Transport sehr großer Datenmengen gibt es von Oracle den Oracle Public Cloud Data Transfer Service. Dieser dient dem physischen Transport von Datenmengen bis zu 400 TByte. per Transfer. Die Daten werden mittels Storage Appliance im Kundenrechenzentrum geladen, transportiert und im Oracle Cloud Rechenzentrum in das Kunden-System hochgeladen.   Sonderformen Oracle IaaS Neben den klassischen IaaS-Themen gibt es von Oracle eine Reihe von Services die der Infrastruktur zugeordnet werden. Oft überzeugt das Cloud-Konzept, findet aber keine praktische Anwendung im eigenen Unternehmen. Hierfür kann es eine Reihe von Gründen geben, zum Beispiel gibt es gesetzliche Regularien die verhindern, dass Daten außerhalb des eigenen Rechenzentrum gespeichert werden dürfen, ein anderer Grund können hohe Anforderung an Netzwerk-Latenzen und -Bandbreiten sein. In diesem Fall bietet die Oracle Cloud Machine die Lösung. Hierbei handelt es sich um eine Hardware und Softwarelösung, die von Oracle im Kundenrechenzentrum betrieben wird. Die Software entspricht der Oracle Public Cloud Software und die Abrechnung erfolgt Monatlich. Dieses Konzept verspricht eine In-House-Cloud-Lösung mit 0% Capex und 100% Opex. Für die Migration von virtualisierten Applikationen aus Kundenrechenzentren in die Oracle Public Cloud bietet Oracle Ravello die ideale Lösung. KVM oder VMWare basierende Applikationen werden nahezu ohne Änderung und automatisiert in die Oracle Cloud migriert. Die Applikationen werden in Ravello geladen, Abhängigkeiten geprüft oder ggf. geändert und anschließend kann die Applikation direkt in die Oracle Cloud geladen werden. So ist ein Umstieg von einer In-House-Virtualisierungslösung auf eine Public Cloud kinderleicht. Das Thema Microservices ist aus der modernen Programmierung nicht mehr wegzudenken. Um Microservices in Docker Containern bzw. Images bereitzustellen, zu verwalten und zu betreiben bietet der Oracle Container Cloud Service die ideale Umgebung. Docker oder Mesos basierende Systeme können direkt in den Container geladen und betrieben werden.   Hier zur Praxis, der Nutzung eines Bare Metal Cloud Service: Oracle Bare Metal Cloud Service - In wenigen Minuten zum Bare Metal Server

Die Oracle Cloud bietet zwei Arten von Infrastruktur Services, Elastisch und Dediziert. Beide Gruppen unterscheiden sich in der Exklusivität der Ressourcennutzung. Beim...

Sicherheit

Oracle Security Philosophie

Oracle bietet im Bereich IT Sicherheit bzw. Security vielfältige Unterstützungsmöglichkeiten für OnPremise Produkte bzw. Architekturen, in der Cloud und hybriden Modellen . Security bei Oracle besitzt viele verschiede Sichtweisen: technisch: Implementierte Sicherheit in den angebotenen On-Premise bzw. Cloud Produkten spezielle On-Premise bzw. Cloud Security Produkte wie eine Datenbankfirewall Architekturen zur Umsetzung von Security und organisatorisch: Entwicklungs- und Freigabeprozess bei Produkten Organisation bei Oracle für Sicherheit und Compliance Compliance und Zertifizierungen Sicherheit des Cloudbetriebs an sich Die organisatorischen Aspekte sind typischerweise im Kontext der Produkte und Services zu sehen. Daher werden diese organisatorischen Aspekte jeweils bei den technischen Darstellungen mit einbezogen. Als Erklärung der Security Philosophie wurde bislang der sogenante Red Stack herangezogen. Mit Hilfe dieses Bildes lassen sich die Absicherung in den Schichten, zwischen den Schichten und zwischen den Systemen darstellen. Auch die von Oracle verwendeten Begriffe wie "defense in depth" oder "Inside-Out" passen in diese Darstellung. Cloud ergänzt den RedStack lediglich um den Betriebsaspekt. Red Stack heisst nicht dass die Lösungen alle von Oracle kommen müssen. Durch die Unterstützung der jeweiligen Standards werden herstellerunabhängige Architekturen unterstüzt. Kern der Security Philosophie von Oracle ist: Schutz jeder Schicht (protect every layer) Schutz beginnt so "tief" wie möglich (push down security the stack) Schutz als Standard (security should always be on) Weiterführende Informationen haben wir nach einzelnen Themenbereichen aufgeteilt: Oracle Public Cloud Security Alle Artikel zu Security  

Oracle bietet im Bereich IT Sicherheit bzw. Security vielfältige Unterstützungsmöglichkeiten für OnPremise Produkte bzw. Architekturen, in der Cloud und hybriden Modellen . Security bei Oracle besitzt...

IaaSundPaaS

Sicherheit in der Oracle Public Cloud

Oracle betrachtet das Thema Cloud Security aus zwei Perspektiven: Sicherheit in den angebotenen Cloud Services, zum Beispiel Verschlüsselung und der Sicherheit der Cloud an sich. Cloud Security kann in Bezug auf die eingesetzten Technologien, auf die Personen, die den Betrieb sicherstellen und auf die Rechenzentren, die diese Dienste bereitstellen, betrachtet werden. Prozesse und Richtlinien definieren dabei das Zusammenwirken. Werden Cloud Services genutzt, teilt sich diese Verantwortung zwischen dem Kunden und dem Cloud Provider auf, dies wird als "Shared Responsibilities" definiert. Die Basis der Nutzung von Angeboten eines Cloud Providers ist die sogenannte Auftragsdatenverarbeitung. Oracle ist dabei der Auftragsdatenverarbeiter (Data Processor) und nicht der Verantwortliche (Data Controller). Verallgemeinert bedeutet dies, dass der Kunde Eigentümer und Verantwortlicher der Daten ist und bleibt. Die Aufteilung der Verantwortlichkeiten ist je nach Art des Cloud Services verschieden. Die detailliertere Beschreibung der Verantwortlichkeiten des Kunden findet sich in den Hosting Policies und den entsprechenden Servicedokumentationen. Die Trennlinie kennzeichnet die Verantwortlichkeiten von Oracle (weiß) und die des Service-Nutzers (orange). Oracle stellt und managt die Basisdienste je nach Cloud Typ bzw. Service. Bei Infrastructure as a Service (IaaS) stellt Oracle das Rechenzentrum und die Infrastruktur bestehend aus Netzwerk, Compute und Storage. Beim Storage wird eine entsprechende Redundanz transparent bereitgestellt. Um Server für Kunden verwalt- und nutzbar zu machen, kommen entweder Virtualisierungslayer (Verantwortlichkeit wie im Bild) oder Provisionierungskomponenten (Bare Metal Cloud, gestrichelte Linie) zum Ansatz. Alle weiterführenden Services stellt oder provisioniert der Kunde als Service-Nutzer selbst. Damit ist der Kunde für die sichere Konfiguration verantwortlich. Ausgehend von einem „alles-ist-verboten“ Ansatz konfiguriert der Kunde entsprechend Accounts, Zugänge, Netzwerke, Verschlüsselungen, Verfügbarkeiten sowie Backups. Je nach Service ist dabei auch Patching und Backup/Restore über die Weboberflächen möglich. Platform as a Service (PaaS) stellt die Services “vorkonfiguriert” zur Verfügung. Je nach Art des Services ist der Kunde auch für Security und administrative Aufgaben verantwortlich. Abhängig vom PaaS Service ist ggf. ein Betriebssystem mit enthalten, zum Beispiel beim Provisionieren eines Service. Es wird ebenfalls von einem „nichts-ist-erlaubt“ Ansatz gestartet, bei dem Accounts, Zugänge, Netzwerke, Verschlüsselungen, Verfügbarkeiten sowie Backups konfiguriert und das Patching durchgeführt werden muss. Bei einem höherwertigen PaaS Service wie zum Beispiel DB Schema Service oder Content Cloud führt Oracle einen Teil der Aufgaben, wie Patching der Datenbank, durch. Die detailliertere Beschreibung der Verantwortlichkeiten des Kunden findet sich in den Hosting Policies und den entsprechenden Servicedokumentationen (Link siehe weiterführende Informationen). Fazit Oracle bietet mit der Oracle Cloud die Nutzung von sicheren IaaS, PaaS und SaaS Cloud-Services. Diese werden entweder aus einem Cloud Rechenzentrum heraus oder mit der Oracle Cloud Machine (Cloud@Customer) im Rechenzentrum des Kunden oder dessen Hoster bereitgestellt. Durch Verwendung gleichartiger Technologien in den Cloud Services wie in lokal installierten Oracle Produkten kann das schon gewonnene Know How weitergenutzt und mit den gleichen Security Policies abgesichert werden. Auch lassen sich Szenarien wie das Verschieben in die Cloud, Lift&Shift, Testen in Cloudumgebungen oder eine hybride Nutzung abbilden.   Zusammengefasst besteht die Oracle Cloud aus sicheren Produkten, die in einer Sicherheitsarchitektur bereitgestellt werden. Sie wird unter Berücksichtigung von Sicherheitsgesichtspunkten ausgerollt, sicher betrieben und regelmäßig durch Unabhängige überprüft. Das folgende Bild zeigt die Adoption durch unsere Kunden: Weitere Informationen Oracle Cloud sowie weitere Informationen und Dokumentationen: https://cloud.oracle.com Definition der Oracle Public Cloud, die Policies: http://www.oracle.com/us/corporate/contracts/cloud-services/index.html Cloud Security Services Weiterführende Informationen zu Security und Oracle:http://www.oracle.com/security

Oracle betrachtet das Thema Cloud Security aus zwei Perspektiven: Sicherheit in den angebotenen Cloud Services, zum Beispiel Verschlüsselung und der Sicherheit der Cloud an sich. Cloud Security kann in...