Identity management pro servery

emtey

Re:Identity management pro servery
« Odpověď #15 kdy: 24. 10. 2014, 11:29:50 »
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.


Re:Identity management pro servery
« Odpověď #16 kdy: 24. 10. 2014, 11:43:18 »
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...

Re:Identity management pro servery
« Odpověď #17 kdy: 24. 10. 2014, 12:00:06 »
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...

citanus2

Re:Identity management pro servery
« Odpověď #18 kdy: 24. 10. 2014, 12:03:52 »
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..: (

jenda

Re:Identity management pro servery
« Odpověď #19 kdy: 24. 10. 2014, 15:47:10 »
co tohle ? kdysi jsem s tim trochu pomahal http://www.ami-kdm.cz/co-je-key-distribution-manager


Dzavy

Re:Identity management pro servery
« Odpověď #20 kdy: 24. 10. 2014, 17:23:02 »
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.

pepa

Re:Identity management pro servery
« Odpověď #21 kdy: 24. 10. 2014, 17:24:51 »
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

Ivan

Re:Identity management pro servery
« Odpověď #22 kdy: 24. 10. 2014, 20:33:49 »
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?

fahacz

Re:Identity management pro servery
« Odpověď #23 kdy: 24. 10. 2014, 20:36:17 »

Trident

Re:Identity management pro servery
« Odpověď #24 kdy: 25. 10. 2014, 18:12:04 »
Citace
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).