Fórum Root.cz
Hlavní témata => Server => Téma založeno: Vojta 23. 10. 2014, 08:38:54
-
Ahoj, sháním radu ohledně centrálního identity managementu.
Jsem administrátorem několika linux serverů. Přístupy na server ověřuji pomocí Kerbera.
Z auditního nálezu vyplývá, že není bezpečné trvale disponovat privilegovanými účty.
Proto bych chtěl na cílových serverech přidat skupinu, jejíž členové by měli neomezený přístup definovaý v sudoers. Něco jako "%admin ALL=(ALL) ALL"
Ve výchozím stavu by měl administrátor serveru pouze základní administrativní oprávnění, například procházení logů apod. Toto by se definovalo také v sudoers.
Sháním Identity Manager s webovým rozhraním, umožňující vzdálené přiřazení uživatele do dané skupiny.
Testoval jsem například IPA server, ale ten toto patrně neumožňuje (nebo jsem nepřišel na to jak).
Jak to řešíte ve firmách vy?
Děkuji
-
Proc vyzadujes webovy rozhrani? Imho by bohate stacilo dobre vymyslet politiky, podle nich nastavit prava skupinam v sudoers a pridani uzivatele do skupiny je pak jeden prikaz - nevidim moc duvod, proc mitna jeden prikaz webovy rozhrani...
P.S. osobne si myslim, ze sudo s pravama ke vsemuneresi vubec nic, ale jestli je motivaci zavdecit se auditu, tak to je pak potreba, to je jasny.
-
Z auditního nálezu vyplývá, že není bezpečné trvale disponovat privilegovanými účty.
Jak to řešíte ve firmách vy?
Po návštěvě auditorů se vše vrací zpět jak to bylo před návštěvou :)
Schválně se zkus zeptat jak si představují administraci serverů bez práva root a budou blábolit nesmysly. Procházení logů není administrace, ale monitoring.
Standardně se to řeší tak, že heslo na root mají pouze vybraní lidé a ostatní administrátoři mají přístup k právům root přes sudoers. Motivace k tomuto počínání není bezpečnost, ale lenost měnit hesla na root pokaždé když nějaký administrátor opustí firmu.
-
ale lenost měnit hesla na root pokaždé když nějaký administrátor opustí firmu.
Vy jste ještě neobjevili přihlašování certifikátem? ;)
-
Stává se, že certifikát nelze použít a je nutno napsat heslo na root z klávesnice. Jistě na to přijdete sám kdy se tak děje.
-
Stává se, že certifikát nelze použít a je nutno napsat heslo na root z klávesnice. Jistě na to přijdete sám kdy se tak děje.
Počkej, žerty stranou, to by mě fakt zajímalo, v jaké situaci nejdou použít certifikáty a zároveň jde použít sudo. Napadá mě jenom případ, že by šlo o virtuál (-> nedá se použít USB token) a nejelo tam ssh (buď schválně, nebo kvůli závadě), takže by bylo potřeba se hlásit přes KVMko do konzole.
Nebo ještě jsem slyšel historku o přístupu k systémům nejmenovaného operatárora, kde se muselo snad přes nějakou VPNku dostat na web, kde v javě běžel KVM plugin :)
Oboje by šlo ještě řešit pomocí OTP, to by asi pořád bylo lepší než sudo.
-
Fyzický přístup, KVM, iLO, iDRAC a virtualizační konzole.
-
Fyzický přístup, KVM, iLO, iDRAC a virtualizační konzole.
No takže prostě pro případ, že nejede sshčko, páč tohle snad normálně nepoužívate, ne?
-
No takže prostě pro případ, že nejede sshčko
Bingo
-
Webové rozhraní pro osoby, které budou mít právo udělit konkrétní práva administrátorům na určeném serveru.
Řešení, jakým jsou certifikáty, neodpovídá zadáni. Řeší jen autentizaci, kterou, jak jsem psal, řeším Kerberosem.
Upřesním, jak by mělo vypadat workflow.
1. Produkční incident/change a potřeba privilegovaného účtu na konkrétmín stroji
2. Žádost o privilegovaný účet na serveru/skupině serverů
3. Schválení žádosti o privilegovaný účet na konkrétním serveru po dobu nutnou k nápravě/úpravě
4. Nastavení oprávnění například přiřazením do skupiny
5. Po vypršení času uvedeným v žádosti, přenastavení oprávnění účtu do výchozího stavu
Aktuálně mám otestované dva produkty a ani jeden zcela neřeší mé požadavky.
Prvním je komerční PIM od CyberArk, druhým je IPA na RHEL6.
-
Webové rozhraní pro osoby, které budou mít právo udělit konkrétní práva administrátorům na určeném serveru.
A ty osoby, které mají mít právo rozhodovat o přístupu k serveru neumí spustit
# ssh bigboss@server1 "usermod -Gwebadmins lojza"
a potřebují na to webové udělátko, které se zase bude muset zabezpečovat?
Řešení, jakým jsou certifikáty, neodpovídá zadáni. Řeší jen autentizaci, kterou, jak jsem psal, řeším Kerberosem.
Jasně, to byla jenom drobná offtopic konverzace s Kolemjdoucím.
-
...
Jak to řešíte ve firmách vy?
Děkuji
Mimochodem, co budes delat, kdyz se neco podela ve 3 rano? Budes cekat do rana, nez se sejde vedeni a schvali napravu? To je taky predpokladam duvod, proc chces web - nebot schvalovani provadi BFUcko, pro ktery je shell sprosty slovo? A co budes delat v situaci, kdy jedina moznost bude ke stroji fyzicky prijit? To prijde pan generalni a bude rucabo na konzoli zadavat cosi, aby moh admin stroj uvest do chodu? A zaroven to znamena, ze v dotycne firme nikdo, vcetne adminu, nema pristup k zelezu? Protoze pokud ma, tak si stejne muze delat co chce?
Ne ze bych nechapal voco go, jen se te snazim upozornit, jaky aspekty sebou administrace nese, a ze podobny zabezpecovani sebou nese i velmi neprijemne dusledky, ktere mohou firmu ve finale stat vic, nez co ji to potencielne prinese.
-
nebot schvalovani provadi BFUcko, pro ktery je shell sprosty slovo?
Pokud nekdo takovej ma rozhodovat o tom, jestli Franta Vomacka potrebuje nebo nepotrebuje root přístup na server db-a123b.nasefirma.cz, tak to je dost zajímavý samo o sobě :)
-
Myslím, že není dostupného nic lepšího než FreeIPA :-)
U nás ve firmě to používáme pro řízení přístupu ke všem systémům.
-
Mimochodem, co budes delat, kdyz se neco podela ve 3 rano?
Pokud ještě nebudu vzhůru, vzbudí mne někdo ze Service Desku. Připojím se pomocí VPN do firmy, zažádam o přístup na server, který mi následně schválí vyzvednutí roota či jiného NPA z uložiště hesel. To je běžná praxe ve velkých firmách. Myslíte si, že administrátoři v bankách disponují privilegovanými účty bez omezení? Nikoliv.
Pokud neznáte odpověď na mou otázku, prosím neodpovídejte.
-
nebot schvalovani provadi BFUcko, pro ktery je shell sprosty slovo?
Pokud nekdo takovej ma rozhodovat o tom, jestli Franta Vomacka potrebuje nebo nepotrebuje root přístup na server db-a123b.nasefirma.cz, tak to je dost zajímavý samo o sobě :)
Proc? Prijde admin, rekne, ze musi provest to a to a zamestnanec, co ma na starosti bezpecnost mu pripadne prava prideli, vyplni do protokolu duvod udeleni prav, datum a nasledne po par dnech mu je i odebere.
-
Proc? Prijde admin, rekne, ze musi provest to a to a zamestnanec, co ma na starosti bezpecnost mu pripadne prava prideli, vyplni do protokolu duvod udeleni prav, datum a nasledne po par dnech mu je i odebere.
Mě zaráží, že posouzení oprávněnosti takové žádosti má jako poslední instance v ruce někdo, kdo neumí/nechce použít ssh.
Ještě bych pochopil, kdyby to ten člověk nedělal sám, ale jenom schválil ticket, na základě kterýho by potom nějaký klikač někde kliknul v administraci serveru. Ale to zas už je situace, kdy na těch serverech snad mám nějaký configuration management, který tohle umí udělat a který tak jako tak už má nějaké rozhraní.
Já prostě nerozumím tomu, proč se ausgerechnet zařazení uživatele do nějaké skupiny musí řešit přes webové rozhraní. Tazatel na to buď nehodlá odpovědět nebo nechápe otázku, tak to nechme koňovi...
-
Ale to zas už je situace, kdy na těch serverech snad mám nějaký configuration management, který tohle umí udělat a který tak jako tak už má nějaké rozhraní.
Ještě teda abych tohle doplnil a odpověl na otázku "jak to děláte vy":
1. servery se nastavují Saltem
2. saltové konfiguráky jednotlivých serverů jsou verzovány gitem
3. v saltové konfiguraci je nadefinované, jaké klíče mají být v /root/.ssh/authorized_keys
nebo:
3. v saltové konfiguraci je nadefinované, jací lokální uživatelé na serveru jsou a jakých skupin mají být členové
4. (pokud bych to chtěl) v /etc/sudoers by bylo nadefinováno, jaké příkazy můžou členové kterých skupin spouštět - zatím jsem nepotřeboval
Takže ten zmíněný use case:
1. admin Venca zažádá o přístup
2. boss Lojza schválí
3. autorizovaná osoba Pepa provede úpravy saltovské konfigurace tak, aby byl Venca členem skupiny dbadmins (změna jednoho řádku) a zpropaguje na server
4. změna je zanesena a zdokumentována v gitu
5. Venca se na server přihlásí a je členem skupiny dbadmins
Akorát bych si dal pozor na to, že Venca zůstává členem skupiny dbadmins dokud se neodhlásí - nevím, jestli sudo členství ve skupině pokaždé kontroluje oproti systému nebo jenom bere aktuální vencovy skupiny té konkrétní shell session. Kdyby si Venca nechal puštěný shell pod screenem/tmuxem, zůstane členem skupiny v téhle session i dál...
-
Proto bych chtěl na cílových serverech přidat skupinu, jejíž členové by měli neomezený přístup definovaý v sudoers. Něco jako "%admin ALL=(ALL) ALL"
Ve výchozím stavu by měl administrátor serveru pouze základní administrativní oprávnění, například procházení logů apod. Toto by se definovalo také v sudoers.
Sháním Identity Manager s webovým rozhraním, umožňující vzdálené přiřazení uživatele do dané skupiny.
Testoval jsem například IPA server, ale ten toto patrně neumožňuje (nebo jsem nepřišel na to jak).
Tohle a zaroven i mnohem vic ipa pohodlne poskytuje. Nicmene pokud je zatezko si precist zakladni dokumentaci, tak radeji nic podobneho nenasazuj..: (
-
co tohle ? kdysi jsem s tim trochu pomahal http://www.ami-kdm.cz/co-je-key-distribution-manager (http://www.ami-kdm.cz/co-je-key-distribution-manager)
-
IPA podle me umi nastavovat pomoci sudoers opravneni pro jednotlive skupiny/uzivatele na jednotlive hosty...a obecne nic moc lepsiho (v open source) nez IPA asi nebude.
-
Kerberos pro autentizaci uzivatelu
LDAP pro autorizaci uzivatelu, respektive skupiny jsou presunute do LDAP
Vsichni jsou users bez prav, ale nekteri clenem sudoers
myslim ze ta freeIPA je taky tak postavena
-
A co takovyhle pristup?
- Na servery se da dostat pouze pres "jump-start" server.
- Vsechno co na serveru udelate se nahrava a uklada
Chapu, ze se dneska cim dal tim vic v IT resi oddelovani roli. Ale to ze apriori neverite svym zamestancum vas muze prijit sakra draho. Nejakej security expert prohlasi, ze ten co toci cervenym koleckem NESMI nikdy tocit i zelenym - na to musi byt jiny clovek(anebo jiny tym). Ok co kdyz ale nastane situace, kdy potrebujete tocit obema koleckama najednou?
-
Mrknětě zde.
https://oss.gonicus.de/labs/gosa/
-
Mimochodem, co budes delat, kdyz se neco podela ve 3 rano?
Pokud ještě nebudu vzhůru, vzbudí mne někdo ze Service Desku. Připojím se pomocí VPN do firmy, zažádam o přístup na server, který mi následně schválí vyzvednutí roota či jiného NPA z uložiště hesel. To je běžná praxe ve velkých firmách. Myslíte si, že administrátoři v bankách disponují privilegovanými účty bez omezení? Nikoliv.
Pokud neznáte odpověď na mou otázku, prosím neodpovídejte.
Ano disponujeme privilegovanymi ucty bez omezeni, jinak bychom nemohli pracovat - nahozeni systemu z jineho disku v SAN, bootovani ze site, prenastaveni na boot z jineho pole, spusteni HW diagnostiky pro vyjezd technika, vypnuti vadne procesorove desky kdyz ma technik otevrenou skrin(komponenty se meni za behu) atd. Ale malokdy je pouzivame protoze to musime zduvodnit auditu nebo v ticketu. Vystupy z konzoli se loguji a tak to jde videt. Pokud neni vylozene nutne tak pouzivame ucty neprivilegovane ktere maji povolene vetsinu akci a je to logovane.
Centralni uloziste hesel fungovalo do te doby nez spadlo samotne centralni uloziste hesel a na servery se neslo normalne dostat (neslo o linux, nedalo se to snadno hacknout pres init).