Jak mohu skrýt heslo ve skriptech shellu? Existuje řada skriptů, které přistupují k databázi. Pokud otevřeme skript, ostatní si také uvědomí uživatelské jméno a heslo. Takže pokud někdo ví, jak se schovat, dejte mi prosím vědět.
Mám jeden způsob:umístěte heslo do souboru a udělejte soubor jako skrytý a nikdo k němu nebude mít přístup (změňte oprávnění a použijte soubor ve skriptu při přístupu k databázi).
Přijatá odpověď:
První Jak již řeklo několik lidí, je nezbytné uchovávat přihlašovací údaje odděleně od skriptu. (Kromě zvýšené bezpečnosti to také znamená, že můžete znovu použít stejný skript pro několik systémů s různými přihlašovacími údaji.)
Za druhé , měli byste zvážit nejen zabezpečení přihlašovacích údajů, ale také dopad, pokud/když budou tyto přihlašovací údaje ohroženy. Neměli byste mít pouze jedno heslo pro veškerý přístup k databázi, měli byste mít různé přihlašovací údaje s různými úrovněmi přístupu. Můžete například mít jednoho uživatele DB, který má schopnost provádět vyhledávání v databázi – tento uživatel by měl mít přístup pouze pro čtení. Jiný uživatel může mít oprávnění vkládat nové záznamy, ale ne je mazat. Třetí může mít oprávnění mazat záznamy.
Kromě omezení oprávnění pro každý účet byste měli mít také omezení ohledně toho, odkud lze jednotlivé účty používat. Účet používaný vaším webovým serverem by například neměl mít povoleno připojení z jiné IP adresy, než je adresa webového serveru. Účet s úplnými kořenovými oprávněními k databázi by měl být skutečně velmi omezen, pokud jde o to, odkud se může připojit, a nikdy by neměl být používán jinak než interaktivně. Zvažte také použití uložených procedur v databázi, abyste přesně omezili, co může každý účet provádět.
Tato omezení je třeba implementovat na straně systému DB-server, takže i když je kompromitována klientská strana, omezení z ní nelze změnit. (A samozřejmě, DB server musí být kromě konfigurace DB chráněn firewally atd.)
V případě DB účtu, který má povolen pouze omezený přístup pouze pro čtení a pouze z konkrétní IP adresy, možná nebudete potřebovat žádné další přihlašovací údaje, v závislosti na citlivosti dat a zabezpečení hostitele skriptu. je utíkáno z. Jedním příkladem může být vyhledávací formulář na vaší webové stránce, který lze spustit s uživatelem, který má povoleno používat pouze uloženou proceduru, která extrahuje pouze informace, které budou prezentovány na webové stránce. V tomto případě přidání hesla ve skutečnosti nepřináší žádné další zabezpečení, protože tyto informace již mají být veřejné a uživatel nemá přístup k žádným dalším datům, která by byla citlivější.
Také se ujistěte, že připojení k databázi je provedeno pomocí TLS, jinak kdokoli naslouchající v síti může získat vaše přihlašovací údaje.
Třetí , zvažte, jaký druh přihlašovacích údajů použít. Hesla jsou jen jedna forma a nejsou nejbezpečnější. Místo toho můžete použít nějakou formu páru veřejného/soukromého klíče nebo AD/PAM nebo podobně.
Čtvrté , zvažte podmínky, za kterých bude skript spuštěn:
Související:Zdrojový kód netstat?Pokud se spouští interaktivně, měli byste při spuštění zadat heslo nebo heslo k soukromému klíči nebo soukromému klíči nebo být přihlášeni pomocí platného lístku Kerberos – jinými slovy, skript by měl dostat své přihlašovací údaje přímo od vás v době, kdy jej spouštíte, namísto čtení z nějakého souboru.
Pokud je spouštěn z webového serveru, zvažte nastavení přihlašovacích údajů v době, kdy webový server spouštíte. Dobrým příkladem jsou SSL certifikáty – mají veřejný certifikát a soukromý klíč a soukromý klíč má heslo. Soukromý klíč můžete uložit na webový server, ale musíte k němu při spuštění Apache zadat heslo. Můžete mít také přihlašovací údaje na nějakém druhu hardwaru, jako je fyzická karta nebo HSM, které lze po spuštění serveru odebrat nebo uzamknout. (Samozřejmě nevýhodou této metody je to, že se server nemůže sám restartovat, pokud se něco stane. Dávám přednost tomu před rizikem ohrožení mého systému, ale váš počet najetých kilometrů se může lišit…)
Pokud se skript spouští z cronu, je to nejtěžší část. Nechcete, aby se přihlašovací údaje povalovaly kdekoli ve vašem systému, kde k nim mohl někdo přistupovat – ale chcete je mít povalované, aby k nim měl váš skript přístup, že? No, ne tak úplně správně. Zvažte, co přesně skript dělá. Jaká oprávnění potřebuje k databázi? Lze to omezit, aby nezáleželo na tom, jestli se s těmito oprávněními připojí nesprávná osoba? Můžete místo toho spustit skript přímo na serveru DB, ke kterému nemá nikdo jiný přístup, místo ze serveru, který má jiné uživatele? Pokud z nějakého důvodu, který mě nenapadá, naprosto musíte mít skript spuštěný na nezabezpečeném serveru a to musí být schopen udělat něco nebezpečného/destruktivního... teď je ten správný čas přehodnotit svou architekturu.
Pátá Pokud si ceníte bezpečnosti své databáze, neměli byste tyto skripty spouštět na serverech, ke kterým mají přístup jiní lidé. Pokud je někdo přihlášen do vašeho systému, bude mít možnost získat své přihlašovací údaje. Například v případě webového serveru s certifikátem SSL existuje alespoň teoretická možnost, že někdo bude schopen získat root a získat přístup do oblasti paměti procesu httpd a extrahovat přihlašovací údaje. V poslední době došlo k nejméně jednomu zneužití, kdy to bylo možné provést přes SSL, aniž by bylo nutné, aby byl útočník přihlášen.
Zvažte také použití SELinux nebo AppArmor nebo čehokoli, co je pro váš systém dostupné, abyste omezili, kteří uživatelé mohou co dělat. Umožní vám zakázat uživatelům, aby se i jen pokusili připojit k databázi, i když se jim podaří získat přístup k přihlašovacím údajům.
Pokud vám to všechno zní jako přehnané , a nemůžete si to dovolit nebo na to nemáte čas – pak byste podle mého (arogantního a elitářského) názoru neměli ve své databázi ukládat nic důležitého nebo citlivého. A pokud neukládáte nic důležitého nebo citlivého, pak není důležité, kde ukládáte své přihlašovací údaje – v takovém případě, proč vůbec používat heslo?
Související:Generovat čtyři náhodná slova ze seznamu pro hesla podobná XKCD?Naposled , pokud se absolutně nemůžete vyhnout uložení nějakého druhu přihlašovacích údajů, můžete mít přihlašovací údaje pouze pro čtení a vlastněné uživatelem root a root by mohl udělit vlastnictví na mimořádně dočasném základě, když o to požádá skript (protože váš skript by měl ne spouštět jako root, pokud to není nezbytně nutné a připojení k databázi to nevyžaduje). Ale pořád to není dobrý nápad.