Oracle odmítá autentizaci OS podle Oracle Database Security Guide , který říká
Uvědomte si, že parametr REMOTE_OS_AUTHENT byl v aplikaci Oracle Database 11g Release 1 (11.1) zastaralý a je zachován pouze pro zpětnou kompatibilitu.
Většina bezpečnostních informací a nástrojů navíc považuje OS (externí) ověřování za bezpečnostní problém. Snažím se pochopit, proč tomu tak je. Zde jsou některé výhody, které vidím při ověřování OS:
Zvažte následující scénář:
gaius
s externí autentizací, takže v Oracle existuje odpovídající uživatel s názvem ops$gaius
. Když jsem přihlášen do shellu, mohu se také přihlásit přímo do mého schématu Oracle a mé úlohy cronu také nepotřebují heslo vložené do skriptu.rlogin
/rsh
)gaius
a jako tento uživatel spustí SQL * PlusOSUSER
in V$SESSION
) je gaius
a protokolová vzdáleného uživatele jako ops$gaius
To není jen směšně snadné spoof, ale i když si nasadím můj cynický klobouk, Oracle už nemůže vydělat žádné peníze, které by vám prodaly jejich fantastický produkt s jedním přihlášením ... Což mimochodem splní všechny body, které zvýšíte jako výhody autorizace na úrovni OS. Dvě hesla lepší než jedno jsou zcela falešná; většina lidí je stejně nastaví jako stejná (v Oracle neexistuje mechanismus, jak tomu zabránit).
Obecnou zásadou je, že je velmi obtížné bránit se v softwaru, když má útočník fyzický přístup. A nikdy nevěřte klientovi.
Zvyšuje jednotlivé body selhání a zvětšuje rizikovou plochu vašich dat.
Útočník, který získá přístup do systému, bude mít s autentizací OS přístup k databázi. Vyžadováním bezpečnějšího přístupu k databázi musí potenciální útočník eskalovat svá oprávnění v ohroženém systému, aby získal přístup root nebo Oracle, spíše než jakýkoli uživatel.
Tento problém je funkcí externího přístupu k databázi. Pokud není k dispozici žádný externí přístup a stroj je plně zabezpečen, pak otázka oprávnění je neradostná. Pokud však vývojáři mají přístup, oprávnění uživatele na úrovni operačního systému zvyšují rozsah potenciálních bezpečnostních katastrof.
Zvažte použití vícestupňový přístup k omezení rozsahu narušení zabezpečení a poskytnutí přístupu všem uživatelům, aplikacím nebo klientům, které potřebují, aniž byste museli vytvářet účty na úrovni OS pro každou instanci.
Gaius již poukázal na to, proč vzdálené ověřování operačního systému (na rozdíl od ověřování operačního systému Vanilla, kde uživatelům lokálních počítačů dovolujete přístup do databáze bez zadání samostatné heslo) je relativně nejistá.
Očekával bych, že se Oracle pohybuje tímto směrem, protože chce lidi povzbudit k tomu, aby používali podnikové uživatele (nebo plnohodnotnou sadu správy identit) spíše než vzdálené uživatele ověřené operačním systémem. Podnikoví uživatelé mají stejné výhody jako uživatelé ověřeni vzdáleným operačním systémem, ale Oracle ve skutečnosti chodí a zasahuje server služby Active Directory k ověření uživatele. Získáte stejné jednotné přihlášení o výhodách, aniž byste bezpečnostní kontrolu nechali na klientském počítači.
Konkrétně poukazujete na autentizaci identickým stylem, ale rád bych také zdůraznil, že jiné metody vázání databáze nebo jakékoli jiné přihlašování k přihlášení do operačního systému jsou stejně špatné. (ať už jsou to místní soubory hesel, LDAP nebo cokoli pro skutečné uložení přihlašovacích údajů)
Pokud povolíte vzdálené připojení k databázi (nebo webovému serveru nebo k čemukoli, co provádí ověřování), některé OS ignorují pravidla, která mohou být nastavena tak, aby bylo obtížné přenést účty účtování (např. Blokování IP, z nichž přicházejí neúspěšné pokusy; zamykání) uživatelé po dobu po stanoveném počtu chyb atd.). Normálně jsou tato pravidla svázána do sshd
a ne autentizačního systému jako celku.
Pokud by se tedy někdo mohl připojit k databázi/webserveru/cokoli vzdáleně, může si heslo vynutit násilím, protože databáze nemají tendenci mít stejné mechanismy, aby se pokoušely zpomalit pokusy, a poté, co najdou potřebná pověření, ssh.