Direkt zum Inhalt | Direkt zur Navigation

Sektionen

Focus on your applications!

Benutzerspezifische Werkzeuge

Sie sind hier: Startseite / Support / Glossar

Glossar

erstellt von Veit Schiele zuletzt verändert: 14.08.2016 16:15
  • A
  • B
  • C
  • D
  • E
  • F
  • G
  • H
  • I
  • J
  • K
  • L
  • M
  • N
  • O
  • P
  • Q
  • R
  • S
  • T
  • U
  • V
  • W
  • X
  • Y
  • Z

 Ansible
Ansible ist eine Open-Source-Engine, die Software-Provisioning, Konfigurationsmanagement, and Application-Deployment automatisiert.
Architektur Wie die meisten anderen Konfigrationsmanagement-Systeme unterscheidet Ansible zwischen Konfigurationsüberwachung (Control Machine), bei der die Orchestrierung beginnt und Knoten (Nodes), auf denen die Konfigurationsänderung durchgeführt wird. Diese Knoten werden von Ansible via SSH verwaltet wobei die Lage der Knoten im Inventar der Control Machine verwaltet werden.
Um Knoten zu orchestrieren, verteilt Ansible Module zu den Knoten über SSH. Module werden temporär im Knoten gespeichert und kommunizieren mit der Control Machine über ein JSON-Protokoll. Nach der Konfiguration des Knoten verbraucht Ansible weder Ressourcen auf dem Knoten noch ist es für den weiteren Betrieb einer Anwendung auf diesem Knoten erforderlich (agentenlose Architektur).
Designziele minimalistisch Managementsysteme sollten keine zusätzlichen Abhängigkeiten von der Umgebung erfordern. sicher Ansible setzt keine Agenten auf Knoten ein. Nur OpenSSH und Python sind auf den verwalteten Knoten erforderlich. zuverlässig Wenn sorgfältig geschrieben, können Ansible-Playbooks idempotent sein und damit unerwartete Nebenwirkungen auf die verwalteten Systeme vermeiden. leicht erlernbar Playbooks verwenden eine einfache beschreibende Sprache, die auf YAML- und Jinja-Templates basiert. Module Jedes Ansible-Modul kann eigenständig und in einer beliebigen Programmiersprache geschrieben sein. Dabei sollten die Module idempotent sein, was bedeutet, dass selbst wenn ein Vorgang mehrfach wiederholt wird – z.B. bei der Wiederherstellung nach einem Ausfall – das System immer in denselben Zustand versetzt wird.
Inventar Das Inventar ist eine Beschreibung der Knoten, auf die von Ansible zugegriffen werden kann. Standardmäßig wird das Inventar durch eine Konfigurationsdatei im INI- Format beschrieben. Die Konfigurationsdatei listet entweder die IP-Adresse oder den Hostnamen jedes Knotens auf, der von Ansible zugänglich ist. Darüber hinaus können Knoten gruppiert werden.
Ansible kann auch dynamisch Daten aus anderen Systemen beziehen.
Playbooks Playbooks beschreiben Konfigurationen, Deployment und Orchestrierung in Ansible. Das Playbook-Format ist YAML wobei jedes Playbook eine Gruppe von Hosts zu einer Reihe von Rollen zuordnet.
AWX AWX ist eine REST-API, ein Web-Service und eine Web-basierte Konsole. Damit kann die mit Ansible verwaltete IT-Infrastruktur zentralisiert werden mit einem visuellen Dashboard einschließlich Verwaltung aller Inventare, einer rollenbasierten Zutrittskontrolle, Job-Scheduling und Nachrichten.
Weblinks
- Ansible Homepage
- Lorin Hochstein: Ansible – Up and Running
- AWX
 Backend as a Service
Unter BaaS wird eine gehostete Backend-Infrastruktur verstanden, mit der App- oder Mobile-Web-Entwickler in wenigen Schritten ein individuelles Backend konfigurieren können.
MIt BaaS sollen folgende Probleme gelöst werden:

- App- und Web-Entwickler sollen Updates und Erweiterungen schnell veröffentlichen können
- Die klassische Aufteilung in Frontend- und Backend-Entwicklungsteams muss nicht mehr koordiniert werden
- Die Kommunikation mit dem BaaS-Server erfolgt durch APIs.
- Die Nutzdaten können unabhängig vom Endgerät gespeichert werden
- Das Backend skaliert beim Anstieg der Nutzerzahlen
- Durch Pay as you use wird nur die tatsächliche Nutzung bezahlt. Dies macht den Einsatz von BaaS auch für kleine Unternehmen interessant.
 Bootkit
Variante eines Rootkit für den kernel-mode. Dieses kann beim Starten Code einschleusen zum Infizieren z.B. des Master Boot Record (MBR), des Volume Boot Record (VBR) oder des Bootsektors. Auf diese Weise kann dann z.B. die Festplattenverschlüsselung angegriffen werden. Ein Beispiel hierfür ist die Evil Maid Attack, bei dem ein Angreifer ein Bootkit als Ersatz des legitimen Bootloaders auf einem unbeaufsichtigten Computer installiert, um ihn unter seine Kontrolle zu bekommen.
Üblicherweise bleibt die Malware nach dem Laden des Kernels beim Übergang in den protected mode erhalten und ist damit in der Lage, den Kernel selbst zu unterminieren. Das Stoned Bootkit nutz einem kompromittierten Bootloader zum Abfangen von Schlüsseln und Passwörtern.
Mögliche Schutzmechanismen gegen Bootkit-Angriffe sind die Verhinderung von unberechtigtem physischen Zugriff auf das System oder die Verwendung eines Trusted Platform Module, das so konfiguriert sein muss, dass es den Boot-Pfad schützt.
 Bootsektor
Er ist der erste Sektor eines startfähigen Mediums, der Informationen enthält, die zum Starten eines Betriebssystems notwendig sind.
Meist wird mit dem Begriff ein Startprogramm beschrieben, das zum Starten des eigentlichen Betriebssystems verwendet wird.
Gebräuchliche Bootsektoren sind:
Master Boot Record (MBR) Der erste Sektor auf der Festplatte oder anderen partitionierten Datenträgern Volume Boot Record (VBR) Der erste Sektor auf einer Partition
 DMA
Dies ist eine Funktion von Computersystemen, die bestimmten Hardware-Subsystemen erlaubt auf den Hauptspeicher (RAM) zuzugreifen unabhängig von der CPU. Viele Hardware-Systeme verwenden DMA, einschließlich Laufwerk-Controller, Grafik- und Netzwerkkarten.
Mit DMA lassen sich jedoch auch typische side channel attacks durchführen wobei Angreifer in Computer durch High-Speed-Erweiterungsports eindringen können, die ihnen direkten Speicherzugriff gewähren.
Um solche Angriffe zu verhindern können entweder die physischen Verbindungen solcher Ports getrennt oder innerhalb des BIOS oder UEFI deaktiviert werden.
Beispiele für DMA-Verbindungen sind FireWire, CardBus, Expresscard, Thunderbolt, PCI und PCI-Express. Die Schwachstelle besteht jedoch nicht, wenn das PCI-Express- Protokoll nicht im Thunderbolt-Kabel verwendet wird sondern IP over Thunderbolt (IPoTB), wie dies ab Mac OS X Mavericks der Fall ist.
 Intrusion Detection System
Ein Intrusion Detection System (IDS) ist ein Gerät oder eine Software-Anwendung, die ein Netzwerk oder Systeme auf bösartige Aktivitäten oder Regelverstöße hin überwacht. Jede festgestellte Aktivität oder Verletzung wird in der Regel entweder an einen Administrator gemeldet oder zentral gesammelt unter Verwendung eines Security Information and Event Management (SIEM)-Systems. Ein SIEM-System kombiniert Ausgaben verschiedener Quellen und verwendet Alarmfiltertechniken um bösartige Aktivitäten von Fehlalarmen zu unterscheiden. Es gibt ein breites Spektrum von IDS von Antiviren-Software bis zu abgestuften Systemen, die den Datenverkehr eines ganzen Backbone-Netzwerks überwachen. Die häufigste Klassifizierung ist diejenige in Netzwerk- (NIDS) oder hostbasierte (HIDS) Intrusion-Detection-Systeme. Es ist auch möglich, bei IDS zu unterscheiden zwischen signatur- und anomaliebasierter Erkennung. Einige IDS können auch auf bösartige Aktivitäten reagieren und werden daher auch als Intrusion Prevention System bezeichnet.
 Lights Out Management
LOM erlaubt Systemadministratoren die Überwachung von Servern und andere, an das Netz angeschlossene Geräte zu überwachen und zu verwalten. Dies ist unabhängig davon, ob die Maschine eingeschaltet oder ein Betriebssystem installiert ist.
 LUKS
Verschlüsselte Daten werden um einen Header erweitert, in dem Metadaten sowie bis zu acht Schlüssel gespeichert werden. Es bietet die folgenden Vorteile:

- ein standardisiertes Format, wie Informationen über die Art der Verschlüsselung im Header gespeichert werden
- die Vergabe von bis zu acht Schlüsseln sowie
- die Änderung und Löschung von Schlüsseln ohne Umschreiben der verschlüsselten Daten. Der Header, den LUKS in einen Container schreibt, enthält:

- eine Klartext-Kennung
- den verwendeten Verschlüsselungs- und Hash-Algorithmus und
- die Größe des Masterschlüssels Vorteile
- LUKS-Containern können automatisch erkannt und einfach verwaltet werden. Nachteile
- Auch Dritte und Angriffsprogramme können einfach die Verschlüsselung erkennen. Damit wird das glaubhafte Abstreiten schwierig bis unmöglich.
- Der LUKS-Header inkl. der Schlüsseldaten verkleinert zudem den nutzbaren Speicher auf dem Medium üblicherweise um 1028 KiB.
- Sie werden nicht auf dem Medium verteilt repliziert gespeichert. Wenn sie versehentlich überschrieben oder aufgrund eines Hardwaredefekts nicht mehr ausgelesen werden können, sind die Nutzerdaten nicht mehr zu entschlüsseln sofern kein Backup des Headers (z.B. mit cryptsetup gemacht wurde).
 Mandatory access control
MAC ist eine Zugriffskontrolle, durch die das Betriebssystem den Zugriff oder die Ausführung einschränkt. Üblicherweise sind dies meist Prozesses oder Threads, die auf Dateien, Verzeichnisse, TCP/UDP-Ports, Shared-Memory-Segmente, Laufwerke etc. zugreifen wollen. Dabei überprüfen die Authorisierungsregeln des Betriebssystems jedes mal anhand der Sicherheitsattribute der Operationen und Objekte, ob der Zugriff stattfinden kann.
MAC-Implementierungen sind SELinux und AppArmor für Linux oder TrustedBSD für Mac OS X.
 Role Based Access Control
RBAC ist in Mehrbenutzersystemen und Rechnernetzen ein Verfahren zur Zugriffssteuerung und -kontrolle auf Dateien oder Dienste.
Die Komponenten von RBAC um einen Zugriffskontrollmechanismus zu definieren, sind Rollenberechtigungen, Benutzer-Rollen-Zuweisungen und Rollen-Rollen-Beziehungen.
grsecurity ist ein solches RBAC-System.
 Shoulder-Surfing
Direkte Beobachtungstechnik um Passwörter, PINs etc. zu erhalten. Hierzu können auch Überwachungskameras zum Beobachten der Dateneingabe verwendet werden.
 Unified Extensible Firmware Interface
Das Unified Extensible Firmware Interface (UEFI) definiert die Schnittstelle zwischen Betriebssystem und Firmware. UEFI ersetzt das Basic Input/Output System (BIOS). UEFI unterstützt die Ferndiagnose und Reparatur von Computern, auch wenn kein Betriebssystem installiert ist.
EFI’s Position im Software Stack
Secure Boot Ab der UEFI 2.3.1-Spezifikation ist ein Protokoll spezifiziert, das als Secure Boot bezeichnet wird. Dabei wird das Laden von Treibern verhindert, die nicht signiert sind. Bei aktiviertem Secure Boot wird ein öffentlicher Schlüssel, der sogenannte Platform Key (PK) in die Firmware geschrieben. Anschließend können nur noch Treiber von der Firmware geladen werden, die mit diesem Plattformschlüssel signiert wurden. Zusätzliche Key Exchange Keys (KEK) können in eine Datenbank geschrieben werden um weitere Zertifikate zu verwenden.
Secure Boot wird von einer Reihe von Linux-Distributionen unterstützt, einschließlich Fedora ≥ v18, openSUSE ≥ 12.3 und Ubuntu ≥ 12.04.2.
Kritik Als Microsoft 2011 ankündigte, dass Computer für Windows 8 mit aktivem Secure Boot und einem privaten Schlüssel von Microsoft zertifiziert sein müssen, wurde kritisiert, dass dies die Installation alternativer Betriebssystem wie Linux behindere. Microsoft versicherte jedoch, dass dies nicht zu einem Vendor Lock-in führen sollte und präzisierte, dass Windows 8-zertifizierte Computer den Betrieb von Secure Boot im custom mode zulassen und damit zusätzliche öffentliche Schlüssel hinzugefügt werden können, die nicht mit dem privaten Schlüssel übereinstimmen müssen.
Auf der Black-Hat-Konferenz im August 2013 wurde eine Reihe von Secure Boot Exploits für spezifische UEFI-Implementierungen präsentiert. Im August 2016 wurde bekanntgegeben, dass der sog. Golden Key, mit dem Microsoft Betriebssysteme signiert, entdeckt wurde. Mit diesem Schlüssel lassen sich Rootkit- und Bootkit-Angriffe starten. Microsoft erklärte, dass diese Möglichkeit nur für die ARM-Architektur möglich wäre und veröffentlichte zwei Patches.