Existují i jiné způsoby, jak to udělat. Záleží na tom, kdo podle vás přichází po vašem připojovacím řetězci a jaký typ přístupu a úrovně dovedností bude mít. Připojovací řetězec tam někde je, bez ohledu na to, jak se ho snažíte skrýt.
S vědomím, že by připojovací řetězec mohl být hacknut, vždy předpokládám, že bude hacknut, a na druhém konci přijmu opatření.
Na konci DB serveru děláme několik věcí, abychom zajistili, že i když je připojovací řetězec komprimován, data jsou stále bezpečná.
- Uživatel, který je spojen s připojovacím řetězcem, má na serveru prakticky nulová oprávnění. Jediná oprávnění, která mají, jsou EXECUTE a CONTROL na SCHÉMATU, které obsahuje uložené procedury.
- Jediný přístup, který má frontend, je prostřednictvím uložených procedur. Nikdy nepovolujeme frontendu odesílat řetězce SQL.
- Data jsou uchovávána v samostatném schématu než spustitelné soubory, ve schématu DATA má uživatel přidružený k připojovacímu řetězci oprávnění NULA, nemůže se na ně dívat, cítit je ani se jich dotýkat.
- Uložené procedury delegují oprávnění na uživatele bez přihlášení, který má dostatečná oprávnění ke spuštění procesu. (S EXECUTE AS 'no-login User')
To je asi tak všechno, co můžeme udělat. Nenašli jsme způsob, jak zabránit tomu, aby byl připojovací řetězec někde odhalen.
Odpověď na otázku, kterou Alex položil níže. (příliš dlouhý na komentář)
Poznámka. Následující text je pro MS SQL Server, může se vztahovat na jiné systémy DBMS, ale za žádné jiné nemohu ručit.
Databáze obsahuje schéma, schéma obsahuje databázové objekty, jako jsou tabulky, pohledy, uložené procedury. Schmea vám umožňuje ohradit databázové objekty, například, pokud jste měli skupinu tabulek, které měl kdokoli povoleno vidět, pak mohli do SPOLEČNÉHO schématu, pokud jste měli informace o mzdách, které jste potřebovali zabezpečit, mohli byste je umístit to do mzdového schématu. Poté můžete do SCHÉMATU umístit různá bezpečnostní opatření podle typu objektů, které se v nich nacházejí. Graficky vypadají jako složky na pevném disku a pod nimi jsou všechny databázové objekty, které obsahují. Když spustíte server, existuje několik schémat, která se automaticky vytvoří. Ten, který nejlépe znáte, je DBO schmea. Pokud to váš administrátor nastavil jako výchozí schéma, nemusíte si toho být vědomi.
Co děláme, je umístit všechna data do DATA schmea, to znamená, že jsou povoleny pouze tabulky. Pokud bychom tedy měli databázi mezd, datové tabulky by přešly do schématu zvaného dataPayroll.
Uložená procedura je blok nebo bloky kódu SQL, které může databázový server spustit, když je zavolán. Může vrátit tabulku dat nebo jednu hodnotu. Představte si to jako metodu v C#.
Uložené procedury mají vstupní a návratové parametry, které se používají v kódu SQL. Paramatarizované uložené procedury jsou silnou obranou proti útokům SQL Injection.
Náš protokol říká, že všechny uložené procedury a pohledy jsou uloženy ve schématu, kterému předchází „prog“. Takže v případě mzdové databáze jsou všechny objekty, které nejsou daty, uvnitř schématu progPayroll.
Uživatel, který je definován řetězcem připojení, má pak pouze oprávnění Control a Execute pro schéma „prog“. To jim umožňuje volat uloženou proceduru. Uživateli definovanému připojovacím řetězcem jsou odepřena všechna ostatní oprávnění. Tomuto uživateli jsou také všude jinde odepřena VŠECHNA oprávnění. V uložené proceduře je oprávnění k přístupu k datům delegováno na uživatele NO LOGIN, který má oprávnění načíst data ze schématu ‚data‘ pomocí příkazu EXECUTE AS.
Na frontendu NENÍ ŽÁDNÝ SQL. Vše, co front-end programátoři vědí, je název uložených procedur, parametry a návratové typy a hodnoty.
Tímto způsobem, i když se útočníkovi podaří vytrhnout připojovací řetězec z vašeho programu, stále má spoustu práce, aby mohl s vaší databází cokoli udělat, protože uživatel, kterého má, může spustit pouze uloženou proceduru.
Pokud nemáte ponětí, co to je, pak si opravdu potřebujete sehnat DB programátora, který vám systém nastaví.