Benutzerbeiträge von „89.247.173.51“
Aus devops.straight8.de
Für 89.247.173.51 Diskussion Sperr-Logbuch Logbücher
5. Februar 2026
- 17:0817:08, 5. Feb. 2026 Unterschied Versionen +3.234 Bytes N Transparent Data Encryption (TDE) Die Seite wurde neu angelegt: „== Transparent Data Encryption (TDE) == '''Transparent Data Encryption (TDE)''' ist eine Technologie, die von großen Datenbankherstellern (wie Microsoft SQL Server, Oracle und Azure SQL) eingesetzt wird, um ruhende Daten (Data-at-Rest) automatisch zu verschlüsseln. Der Name „transparent“ leitet sich daraus ab, dass die Anwendung, die auf die Datenbank zugreift, von der Verschlüsselung nichts bemerkt. === 1. Funktionsweise === TDE arbeitet auf d…“ aktuell
- 17:0717:07, 5. Feb. 2026 Unterschied Versionen +4 Bytes Daten-Verschlüsselung in der Cloud →2. Encryption at Rest (Ruhende Daten) aktuell
- 17:0217:02, 5. Feb. 2026 Unterschied Versionen +3.246 Bytes N Application Level Encryption (ALE) Die Seite wurde neu angelegt: „== Application Level Encryption (ALE) == Während die Standard-Cloud-Verschlüsselung meist auf der Infrastrukturebene (z. B. Festplattenverschlüsselung) stattfindet, setzt die '''Application Level Encryption (ALE)''' direkt beim Entstehen der Daten an. Hierbei verschlüsselt die Anwendung sensible Informationen, ''bevor'' sie über das Netzwerk an eine Datenbank oder einen Speicher gesendet werden. === 1. Funktionsweise === Im Gegensatz zur transpar…“ aktuell
- 17:0117:01, 5. Feb. 2026 Unterschied Versionen +39 Bytes Daten-Verschlüsselung in der Cloud →2. Encryption at Rest (Ruhende Daten)
- 16:5616:56, 5. Feb. 2026 Unterschied Versionen +147 Bytes Daten-Verschlüsselung in der Cloud Keine Bearbeitungszusammenfassung
- 16:5516:55, 5. Feb. 2026 Unterschied Versionen +3.265 Bytes N Daten-Verschlüsselung in der Cloud Die Seite wurde neu angelegt: „== Daten-Verschlüsselung in der Cloud == Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern. === 1. Encryption in Transit (Datenübertragung) === '''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk b…“
- 16:5516:55, 5. Feb. 2026 Unterschied Versionen +40 Bytes Shared Responsibility Model →2. Verantwortung des Kunden
- 16:5216:52, 5. Feb. 2026 Unterschied Versionen +2.693 Bytes N Shared Responsibility Model Die Seite wurde neu angelegt: „== Das Shared Responsibility Model == Das '''Shared Responsibility Model''' ist eine vertragliche und operative Abgrenzung zwischen einem Cloud-Service-Provider (CSP) wie AWS, Azure oder Google Cloud und dem Kunden. Die goldene Regel lautet: Der Anbieter ist verantwortlich für die Sicherheit '''der''' Cloud, der Kunde ist verantwortlich für die Sicherheit '''in''' der Cloud. === 1. Verantwortung des Cloud-Anbieters === Der Anbieter schützt die Infr…“
- 16:5116:51, 5. Feb. 2026 Unterschied Versionen +4 Bytes Cloud & DevOps Spezialisierung →Tag 1 – Cloud Computing Grundlagen
- 16:4616:46, 5. Feb. 2026 Unterschied Versionen +188 Bytes Resilienz-Mechanismen: Rate Limiting & Circuit Breaking Keine Bearbeitungszusammenfassung aktuell
- 16:4516:45, 5. Feb. 2026 Unterschied Versionen +2.934 Bytes N Resilienz-Mechanismen: Rate Limiting & Circuit Breaking Die Seite wurde neu angelegt: „== Resilienz-Mechanismen: Rate Limiting & Circuit Breaking == In verteilten Systemen können Fehler in einem einzelnen Dienst kaskadierende Effekte auslösen, die das gesamte System lahmlegen. Um dies zu verhindern, kommen Schutzmechanismen zum Einsatz, die die Stabilität der Architektur sicherstellen. === 1. Rate Limiting (Drosselung) === '''Rate Limiting''' kontrolliert die Anzahl der Anfragen, die ein Nutzer oder ein Client innerhalb eines bestimmte…“
- 16:4516:45, 5. Feb. 2026 Unterschied Versionen +58 Bytes Einführung: Sidecar-Proxy mit Envoy →4. Vorteile des Sidecar-Ansatzes aktuell
- 16:4116:41, 5. Feb. 2026 Unterschied Versionen +2.670 Bytes N Einführung: Sidecar-Proxy mit Envoy Die Seite wurde neu angelegt: „== Einführung: Sidecar-Proxy mit Envoy == Das '''Sidecar-Muster''' ist ein Entwurfsmuster in der Softwarearchitektur, bei dem eine Hilfsanwendung (der Sidecar) neben einer Hauptanwendung platziert wird. Der weltweit am häufigsten eingesetzte Proxy für dieses Muster ist '''Envoy''', ein hochperformanter C++ Open-Source-Proxy. === 1. Was ist Envoy? === Envoy wurde ursprünglich von Lyft entwickelt und ist heute ein Projekt der Cloud Native Computing…“
- 16:4116:41, 5. Feb. 2026 Unterschied Versionen +41 Bytes Hochverfügbarkeit →1. Das Sidecar-Prinzip aktuell
- 16:3416:34, 5. Feb. 2026 Unterschied Versionen +5.531 Bytes N Hochverfügbarkeit Die Seite wurde neu angelegt: „== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung == '''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht. === 1. Die drei S…“
- 16:2816:28, 5. Feb. 2026 Unterschied Versionen +4 Bytes Cloud & DevOps Spezialisierung →Tag 1 – Cloud Computing Grundlagen
- 16:2216:22, 5. Feb. 2026 Unterschied Versionen +2.757 Bytes N Container-Orchestrierung in der Cloud Die Seite wurde neu angelegt: „== Container-Orchestrierung in der Cloud == Während ein einzelner Container (z. B. Docker) eine Anwendung verpackt, kümmert sich die '''Orchestrierung''' um das Management von hunderten oder tausenden dieser Container über einen Cluster von Servern hinweg. Der Marktführer in diesem Bereich ist zweifellos '''Kubernetes (K8s)'''. Hier sind die zentralen Konzepte und Aufgaben einer Orchestrierungslösung: === 1. Kernaufgaben der Orchestrierung === Ein…“ aktuell
- 16:2216:22, 5. Feb. 2026 Unterschied Versionen +42 Bytes Cloud & DevOps Spezialisierung →Tag 11 – Docker Grundlagen