Nie wszystko na ALL — bezpieczne konfigurowanie sudo w małych firmach

Zdarza się, że administratorzy — zwłaszcza w małych firmach bez wyspecjalizowanego zespołu IT — wpisują po prostu username ALL=(ALL:ALL) ALL, nie zastanawiając się nad tym, że da się to skonfigurować precyzyjniej. Dla wygody i świętego spokoju dajemy sobie lub współpracownikom pełnię praw przez sudo. I wtedy zaczynają się kłopoty.

Jeśli dopiero zaczynasz przygodę z sudo, warto najpierw zapoznać się z podstawami. Zobacz także nasz wcześniejszy artykuł „Co to jest sudo i jak edytować sudoers?”: https://seohost.pl/pomoc/co-to-jest-sudo-jak-edytowac

Dlaczego ALL=(ALL:ALL) ALL to przesada?

Ten zapis oznacza: użytkownik może na dowolnym hoście wykonywać dowolne polecenia jako dowolny użytkownik (np. root) i dowolna grupa. W praktyce? Pełna władza nad systemem. Nawet przez przypadek.

Autorzy wideo z LearnLinuxTV ostrzegają: to łamanie zasady najmniejszych uprawnień (least privilege), zwiększa powierzchnię ataku i naraża system na błędy użytkownika, który np. niechcący wykona destrukcyjne polecenie (sudo rm -rf /).

Jak skonfigurować sudo tylko do jednej aplikacji?

Nie trzeba wszystkiego pozwalać. Przykład wpisu, który pozwala uruchomić tylko jedno polecenie:

janek ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart apache2

Możesz też zdefiniować listę komend:

janek ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade

Ale uwaga: wpis obejmuje dokładnie te komendy. apt install już nie przejdzie. Aby ograniczenia działały poprawnie:

• Użyj pełnych ścieżek (np. /usr/bin/apt)

• Unikaj aliasów i skryptów, które mogą obejść wpis

• Rozważ Defaults!command_path noexec dla dodatkowej kontroli

Praktyki dla zespołów bez administratora

Nie każda firma ma admina na etat. Co wtedy? Trzeba działać rozsądnie i z wyczuciem. Wiele błędów konfiguracyjnych bierze się z chęci uproszczenia sobie życia – ale nadmierne uproszczenia to ryzyko. Zamiast przydzielać pełne uprawnienia każdemu, kto potrzebuje czegokolwiek związanego z administracją, warto podejść do tematu modularnie i metodycznie.

Nawet jeśli nie mamy administratora, możemy tworzyć uporządkowaną strukturę ról i dostępu. Wystarczy odrobina planu i znajomość narzędzi, które system Linux daje nam do ręki.

• Twórz grupy ról: np. backup, devops, websupport
• Przypisuj prawa przez sudoers.d/ zamiast edytować główny plik sudoers
• Każdy wpis testuj przez visudo -f /etc/sudoers.d/nazwa
• Unikaj wpisów typu ALL=(ALL:ALL) ALL dla zwykłych kont

To nie tylko bezpieczeństwo, ale i porządek.

sudoers.d 

System czyta pliki z katalogu /etc/sudoers.d/. Dlaczego warto z tego korzystać? To rozwiązanie nie tylko ułatwia życie administratorom, ale też minimalizuje ryzyko poważnych błędów konfiguracyjnych. Główny plik sudoers jest wrażliwy: jeden błąd może zablokować dostęp do sudo na całym systemie. Tymczasem sudoers.d pozwala pracować modułowo — dodawać reguły dla konkretnych użytkowników, zespołów czy aplikacji, bez ruszania centralnego pliku.

To podejście jest szczególnie przydatne w środowiskach, gdzie różne osoby potrzebują różnych poziomów dostępu, i gdzie konfiguracje są wdrażane automatycznie (np. przez Ansible czy Chef). To także dobra praktyka przy zarządzaniu wieloma serwerami — łatwiej kontrolować, co kto może, i szybciej wykryć ewentualne błędy.

Dlaczego warto z tego korzystać?

• Nie musisz dotykać pliku /etc/sudoers, więc nie popsujesz całości
• Pliki można przypisać do użytkownika, grupy, aplikacji
• Automatyczne narzędzia (np. Ansible, Chef) lepiej sobie z nimi radzą

Ale uwaga:

• Pliki z kropkami, tyldami lub złymi uprawnieniami są ignorowane
• Użyj visudo -c -f /etc/sudoers.d/nazwa, by sprawdzić błędy

Edycja sudoers bez terminala

Jeśli edytowanie sudoers przez terminal to nie twoja bajka, możesz rozważyć narzędzia takie jak Privilege Manager for Sudo. Pozwala on:

• tworzyć polityki dostępu przez prosty edytor
• wersjonować zmiany
• ustawiać reguły centralnie dla wielu maszyn

To rozwiązanie bardziej enterprise'owe, ale nawet mniejsze firmy mogą na tym skorzystać, zwłaszcza przy pracy zdalnej.

Audyt i kontrola

Sudo może logować wszystko, co jest wykonywane:

• /var/log/auth.log lub /var/log/secure zawiera historię sudo
• Użyj sudo -l, by sprawdzić, co może dany użytkownik
• Privilege Manager rejestruje zmiany w politykach i wykonania
• Dla firm: logi można kierować do SIEM lub auditd