DevOps und Authentifizierung/Autorisierung

Aus den Blog “DevOps und Identity” wird abgeleitet, das Authentifizierung und Autorisierung eine zentrale Bedeutung im Thema DevOps besitzt. Um den Umgang etwas zu erleichtern, möchte ich einen kurzen Abriß zum Thema hier liefern.

Was ist Authentifizierung ?

Als Authentifizierung wird die Aktion definiert, die zur Identifizierung eines Benutzers führt.

Was ist Autorisierung ?

Autorisierung ist der Prozeß, welcher zur Berechtigung eines Benutzers oder Prozess führt.

Es gibt somit einen zentralen Unterschied zwischen Authentifizierung und Autorisierung. Autorisierung ist der Prozeß der nach einer erfolgreichen Authentifizierung durchlaufen wird.

Welche Formen von Authentifizierung gibt es?

Um sich zu authentifizieren ist der Zugriff auf die Möglichkeiten:

  1. Username und Passwort
  2. Token/Key/Muster/Smart Card
  3. PKI/Zertifikat

möglich. Zusätzliche huckepack Methoden wie die 2-Faktor Authentifizierung sind bei allen Varianten denkbar.

Authentifizierung mittels Username und Password:

Diese Form der Authentifizierung ist wohl die am meist verbreitete Methode. Neben dem Usernamen kann auch eine Email-Addresse oder ähnliches verlangt werden. Die Identifizierung erfolgt somit über die Parameter für einen User und für ein Passwort. Sehr oft wird diese Form beim PC Login benutzt.

Authentifizierung mittels Token/Key/Muster/Smart Card:

Die aktuell weit verbreitetste Vertreter dieses Verfahren sind OpenID, OAuth, SAML bzw. Federation oder das Entsperren eines Handy/Tablets.

Authentifizierung mittels PKI/Zertifikat:

Bei der Authentifizierung mittels PKI (Public Key Interface) / Zertifikat wird mittels eines Key Pair operiert. Je nach Implementierung wird bei der Authentifizierung der private Key benutzt – z. B. bei der Erzeugung der Ausweise (Zertifikate) hergenommen. Übermittelt wird dann nur noch der Public Key.  Die wohl meist bekannteste Implementierung ist die Benutzung von HTTP mittels SSL also HTTPS. 

 

Können die Möglichkeit kombiniert werden?

Ja. Dies ist möglich. So können z.B. beim Starten eines PC die Verfügbarkeit einer Smartcard notwendig sein bis sich später der Benutzer mittels Usernamen/Email und Passwort authentifiziert und somit identifiziert. Danach kann einer Benutzer oder Prozeß auf dem Host oder Zielsystem operieren.

Wann werden die diese Authentifikationsmöglichkeiten kombiniert?

Die Kombination des Authentifikationsmöglichkeiten werden immer dann gern benutzt, wenn eine Step-Up Authentifizierung benutzt werden soll. Eine Step-Up Authentifizierung ist eine Verifikation eines Benutzers/Prozeß auf einen zusätzlichen Weg, um eine Berechtigung auf einem speziell gesicherten System zu erwirken. Im Gegenzug zur Step-Up Authentifizierung gibt es eine Step-Down Authentifizierung. Diese Form der Authentifizierung wird immer dann notwendig, wenn sichergestellt werden soll, das der Benutzer der das extra gesicherte System verlässt auch seine zusätzlich erworbene Berechtigung wieder frei-/aufgibt. Leider musste ich beobachten, das diese Form sehr selten in den einzelnen Produkten implementiert ist. Es gibt hier Möglichkeiten – eine Möglichkeit ist z.B. den Browser stoppen und neu starten aber auch elegantere sind möglich.

In einem nachfolgenden Blog geht es weiter mit

„DevOps und Authentifizierung/Autorisierung – Teil 2“
(ausgewählte Verfahren – Sicherheitsriskien der Methoden)   

Veröffentlicht unter DevOps | Verschlagwortet mit , , | Hinterlasse einen Kommentar

DevOps und Identity

Was definiert eine Identity?

Eine Identity wird durch eine ein-eindeutige Zuweisung an eine Person, Gruppe oder einen Prozeß dargestellt. Diese Identity ist Grundlage für Authentifizierung und Autorisierung. Die Ein-Eindeutigkeit der Identity muß gewährleistet sein.

Wann wird eine Identity benutzt?

Eine Identity kommt immer dann zum Tragen, wenn auf ein rollenbasiertes System zugegriffen wird.

Wann gilt eine Identity als kompromittiert?

Eine Identity wird als unsicher/kompromittiert gekennzeichnet, sobald diese mit Authentifizierungsdaten zur Verfügung steht. Dabei ist es unabhängig ob ein Passwort im Klartext oder als Hash nutzbar ist.  Eine beliebte Form des Identity-Diebstahls ist das Sharen von Passwörtern im öffentlichen Bereichen z. B. Source-Einträge in einer Datei auf Dropbox oder Github.  Eine Identity gilt auch dann als kompromittiert, wenn diese über ein Backdoor genutzt werden kann.  Dies wäre z.B. der Fall, wenn ein Trojaner ein User Kerberos Token oder eine Session-/Cookie-ID aus dem Browser benutzt werden kann.

Identity-Diebstahl – und welcher Schaden entsteht?

Folgen wir der Publikation im CT Magazin für Computer und Technik in der Ausgabe vom 16.2.2019 mit dem Titel: „Im Namen des anderen“, dann war 2016 fast jeder dritte Bundesbürger Opfer von einem Identity-Diebstahl betroffen. Bei 29% der Betroffenen kam es zu einem Schaden von durchschnittlich 1.366 Euro. Solche Zahlen und der immer noch anhaltende Trend zu solchen „gängigen und lukrativen Geschäftsmodellen“, so das Bundeskriminalamt [im oben genannten Artikel zitiert die CT dazu aus dem „Bundeslagebild Cybercrime 9/2018″] lässt sich erkennen, dass das Schützen der Identity oberstes Ziel sein muss.

Daraus kann für DevOps nur folgen, dass sicheren Methoden im Umgang mit Identitys höchste Priorität einzuräumen sind.

In einen nachfolgenden Post: „DevOps und Authentifizierung/Autorisierung“  möchte ich einige Möglichkeiten hierfür genauer betrachten/darstellen.

Veröffentlicht unter DevOps | Verschlagwortet mit , , | Hinterlasse einen Kommentar

DevOps, DevSecOps, SecDevOps und SecDevSecOps – Was Ist Das ?

Was ist das : DevOps, SecDevOps, DevSecOps und SecDevSecOps?

Gehen wir als erstes auf den Namen ein. Hinter den Abkürzungen steht für:

DevOps              =               Development &                Operations
DevSecOps       =                Development & Secured Operations
SecDevOps       = Secured Development &                Operations
SecDevSecOps = Sec
ured Development & Secured Operations

Bei der Betrachtung des Vorgehensweise stellt man schnell fest, das einige Praktiken der Automatisierung von Prozessen und Barrierefreiheit zwischen Entwicklern und der IT-Infrastruktur dazu führen schneller, nachvollziehbarer und zuverlässiger Produkte oder Releases, Bugfixes zu entwickelt, zu testen und frei zu geben.

DevOps als Wettbewerbsvorteil, dies wiederspiegelt sich z.B. solchen Aussagen:

„Dank DevOps können wir sehr häufig Releases veröffentlichen, wodurch wir im Wettbewerb einen Vorteil haben. Wir können nun täglich statt nur alle sechs Monate neue Produkte auf den Markt bringen und unseren Kunden Fehlerbehebungen innerhalb weniger Stunden zur Verfügung stellen.“

– Hamesh Chawla, VP of Engineering bei Zephyr

Als massgebliche Grundlage von DevOps/SecDevOps/DevSecOps/SecDevSecOps ist die Zusammenarbeit von mehreren Teams von Devopment und der Infrastruktur. Durch die Zusammenarbeit von Teams kommt es zur einer Vertrauensstärkung, die wiederum dazuführt, dass schellere Software-Releases Wechsel – z.B. die Behebung unplanbarer kriitscher Fehler.

 

Secured Development

Secure Development und Secure Deployment werden auch benannt als S-SDLC (Secure Software Deplopment Life Cycle).  Es werden in jeder Phase der Entwicklung: Checklisten, Templates für Aktivitäten und Protokolle zum Nachvollziehen benutzt.  Ziel ist es, den Benutzern/Entwickern zu helfen, durch Benutzung von Methodiken Security Issues zu vermeiden und so das Security Overall-Level  zu erhöhen.

Im Entwicklungszyklus sind von folgende Punkte enthalten (je nach Bedarf anzupassen):

  • Einführung:
    S-SDLC Framework
  • Training Guideline:
    Aufzeigen von Security Problematiken und wie diese zu verhindern sind – Training System
  • Requirements Phase:
    Risk Evaluation Guideline und Requirements Criteria Doc.
  • Design Phase:
    Security Design Review Guideline und Threat Modeling Guideline.
  • Implement Phase:
    Security Coding Guide(C/C++、JAVA、PHP,C#)
  • Validation Phase:
    Aktivität Level, Security Testing Guideline
  • Release Phase:
    Vulnerability Management und Incident Response Guideline

Secured Operations

Secure Operation hilft um ein sichere, rolenbasierte Infrastuktur aufzubauen, zu verwalten und wieder abzubauen. Dabei wird auf gesicherten Pfaden operiert. Dies inkludiert eine Identity Validation und Authentifizierung als auch das Absichern von Netzwerkwegen.

Die Secured Operations werden unter RDSIM zusammengefasst (je nach Bedarf anzupassen):

  • Role-based Access:
    Die rollenbasierte Zugriffssteuerung unterverwendung von
    Benutzern, Gruppen und Anwendungen mit
    benutzerspezifischen Berechtigungen.
  • Datenspeicherung:
    Beschränkung von Zugriffen und Speichermedien auf
    bestimmte Benutzer/Gruppen und Kommunikationswege
    z.B. https.
  • Sicherheitsrichtlinien:
    Verwendung und Bereitstellung von End-To-End-Lösungen, sowie die Dokumentation von Sicherheitsvorfällen und abgeleitete Handlungsweisen.
    Wie die Empfehlung zur Benutzung neuer Technologien z.B. Next Generation Firewalls.
  • Identitätsrichtlinien:
    Sicherung der Identität von Prozessen und Benutzer oder Gruppen mit Hilfer der Verwendung Authentifizierung z.B Single-Sign-One (SSO) und Multi-Faktor
    Authentifizierung, als auch Step-Up and Step-Down Authentifizierung
  • Monitoring:
    Überprüfung und Bewertung von sicherheitsrelevanter Ereignisse bzw. Kritischer Aktivitäten und Anomalieerkennung. Kritische Ereignisse werden einer detizierten Sicherheitsrichtlinie zugeführt.

DevOps/SecDevOps/DevSecOps/SecDevSecOps meets Agilität

Mit dem Ziel des „Continous Delivery“ werden die Besten Teile der Enwickler und Operatoren vereint, um die Effizienz der Automatisierung im Zuge der Digitalisierung zu erhöhen. Agile Techniken wie Scrum und Agile sind beliebte Methoden, um die Zusammenarbeit der Teams und Innovationskraft zu steigern.

DevOps ist eine Denkweise, eine Methode, eine Vorgehensweise.

Veröffentlicht unter DevOps | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar