HarryHarcourt.ansible_rhel8_cis_benchmarks

HarryHarcourt.Ansible-RHEL8-CIS-Benchmarks

Wszystkie zasługi należą się anthcourtney za oryginalny framework, który znajduje się tutaj: https://github.com/anthcourtney/ansible-role-cis-amazon-linux

Ta implementacja została przetłumaczona na Red Hat Enterprise Linux 8.X i CentOS 8.X (uwaga: nie testowano jeszcze).

Ta implementacja została w wielu miejscach uczyniona idempotentną i nadal jest.

Ta implementacja umożliwia włączenie i konfigurację niektórych usług.

CIS RHEL Linux Benchmark. https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.1.1.pdf

Ta rola została opracowana i przetestowana z systemem Red Hat Linux 8.0 przy użyciu obrazu AWS AMI: ami-079596bf7a949ddf8

Dlaczego warto użyć tej roli?

Jeśli próbujesz uzyskać zgodność z akceptowanym w branży standardem bezpieczeństwa, takim jak PCI DSS, APRA lub ISO 27001, musisz wykazać, że zastosowałeś udokumentowane standardy twardnienia we wszystkich systemach objętych oceną.

Jeśli używasz Red Hat Linux, ta rola ma na celu dostarczenie jednej części rozwiązania do zagadnienia zgodności.

Uwaga na niebezpieczeństwo!

Jeśli rozważasz zastosowanie tej roli na jakichkolwiek serwerach, powinieneś mieć podstawową znajomość standardu CIS Benchmark (lub innych podobnych benchmarków) oraz świadomość wpływu, jaki może to mieć na system.

Proszę poświęć czas, aby zapoznać się ze standardem oraz z konfigurowalnymi wartościami domyślnymi, i wyklucz wszelkie elementy przed zastosowaniem ich w systemie.

Przykłady elementów, które powinny być natychmiast rozważane do wykluczenia (lub przynajmniej do modyfikacji odpowiadających wartości domyślnych), obejmują:

3.4.2 i 3.4.3, które domyślnie skutecznie ograniczają dostęp do hosta (w tym przez ssh) tylko do localhosta.

Przykładowy Playbook

Przykładowy playbook, który używa tej roli, wygląda następująco:

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Bardziej zaawansowany przykład, który zawiera modyfikacje domyślnych wartości oraz wykluczenie niektórych elementów w benchmarku uznawanych za niepotrzebne w fikcyjnym środowisku, wygląda następująco:

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  vars:
    cis_level_1_exclusions:
      - 5.4.4
      - 3.4.2
      - 3.4.3
      - 6.2.13   
    cis_pass_max_days: 45
    cis_umask_default: 002
 
  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Zauważ, że użycie become: yes jest wymagane, ponieważ 99% zadań wymaga dostępu z uprawnieniami.

Zmienne roli

Zobacz defaults/main.yml, aby sprawdzić zmienne, które można nadpisać zgodnie z preferencjami.

Opcje

Tagi (i ich kombinacje) można używać do uruchamiania konkretnego poziomu standardu CIS, sekcji lub pojedynczych zaleceń. Na przykład:

Uruchom tylko zadania poziomu 1

ansible-playbook playbook.yml -t level-1

Uruchom tylko zadania sekcji 3

ansible-playbook playbook.yml -t section-3

Uruchom tylko zadania 1.3.1 i 2.2.10

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Uruchom tylko zadania punktowane

ansible-playbook playbook.yml -t scored

Ograniczenia

Obecnie zaimplementowano tylko elementy poziomu 1 z benchmarku. Elementy poziomu 2 będą dodawane w miarę dostępności czasu.

Nie zaimplementowano następujących kontroli:

3.6.2. Zestawy reguł zapory są specyficzne dla środowiska.
3.6.3. Zestawy reguł zapory są specyficzne dla środowiska.
3.6.4. Zestawy reguł zapory są specyficzne dla środowiska.
3.6.5. Zestawy reguł zapory są specyficzne dla środowiska.
4.2.1.2. Określenie, co powinno być rejestrowane i miejsce docelowe wiadomości jest specyficzne dla środowiska.
4.2.2.2. Określenie, co powinno być rejestrowane i miejsce docelowe wiadomości jest specyficzne dla środowiska.
4.2.2.3. Wbudowana edycja pliku konfiguracyjnego syslog-ng jest uznawana za zbyt niedokładną i najlepiej rozwiązywana przez dostarczony plik konfiguracyjny, który spełnia te i inne pokrewne wymagania.
4.2.2.4. Wbudowana edycja pliku konfiguracyjnego syslog-ng jest uznawana za zbyt niedokładną i najlepiej rozwiązywana przez dostarczony plik konfiguracyjny, który spełnia te i inne pokrewne wymagania.
4.2.2.5. Wbudowana edycja pliku konfiguracyjnego syslog-ng jest uznawana za zbyt niedokładną i najlepiej rozwiązywana przez dostarczony plik konfiguracyjny, który spełnia te i inne pokrewne wymagania.
4.3. Konfiguracja logrotate jest specyficzna dla strony.
5.3.2. Edycja wielu linii w plikach konfiguracyjnych pam jest uznawana za zbyt niedokładną i niebezpieczną, a najlepiej rozwiązywana przez dostarczony plik konfiguracyjny, który spełnia te i inne pokrewne wymagania.
5.3.3. Edycja wielu linii w plikach konfiguracyjnych pam jest uznawana za zbyt niedokładną i niebezpieczną, a najlepiej rozwiązywana przez dostarczony plik konfiguracyjny, który spełnia te i inne pokrewne wymagania.

Kompatybilność

Ta rola jest kompatybilna z następującymi wersjami ansible:

2.0.2
2.1.3
2.2.0
2.3.0

Ta rola nie była testowana z żadnymi innymi wersjami ansible.

Testowanie

Poniższe procesy testowe są stosowane przez twórcę tej roli:

Sprawdzana jest składnia roli. Zobacz make syntax.
Wykonywane jest ansible-review względem roli, a wszelkie ostrzeżenia, które uznano za stosowne, są korygowane. Zobacz make review.
Rola jest stosowana na kontenerze docker przy użyciu zarówno ansible v2.1.3, jak i ansible v2.2. Zobacz make test.

Poniższe testy zostały oznaczone, ale jeszcze nie zostały zaimplementowane: