MS-SQL - zabezpecenie dat
Potreboval by som poradit ohladom MS-SQL Express.
Potreboval by som, aby sa zakaznik nemohol priamo vrtat v datach, ani editovat ani prezerat mimo aplikacie, ktora mu to umozni.
Momentalne do toho nevidim celkom jasne, tak sa potrebujem poradit.
Pod akym uctom by mal bezat server? Pod NETWORK (co sa ponuka ako default pri instalacii) alebo je vhodne na tento ucel vytvorit ine konto?
Ako zabranit kradezi dat? Povedzme, ze vytvorim zalohu db, ako zabranit, aby niekto tu zalohu nedal obnovit na svojom servri (a dostal by sa tym padom k datam)?
Zakaznik samozrejme moze manipulovat s technikou ako chce, v tom mu nemozem zabranit, je to jeho zelezo. Skor sa mi jedna o zabezpecenie db a zabranenie zneuzitia dat, ci uz samotnym zakaznikom, jeho zamestnancami alebo niekym dalsim, kto bude mat fyzicky pristup a potrebne vedomosti.
fyzický přístup = nijak. Se stim smiř.
V nejhorším případě si prostě udělá image celého serveru a bude tak dlouho šťourat v nějakém virtuálu, až to vyšťourá.
Server by měl běžet pod účtem system, pak nejsou problémy
Při instalaci se nastavuje zabezpečení Windows/SQL/kombinované
Pokud se nastaví kombinované nebo Windows, pak má administrátor + přidělení uživatelé přístup k SQL serveru.
Pokud nastavíš autentizaci pouze na SQL, pak bude mít právo pouze definovaný uživatel. V základu SA + další, které si definuješ na serveru. Aplikace pak bude přistupovat k serveru pomocí toho účtu.
Co se týká ochrany dat, pak na prvním místě je zajištění fyzické bezpečnosti - aby se k serveru nikdo fyzicky nedostal. Jinak třeba může zastavit službu, zkopírovat si přímo DB soubory a připojit je na jiném MS SQL.
Co se týká ochrany záloh, můžeš použít šifrovanou zálohu - koukni se na možnost Encrypt backup
Ted me jeste napadlo. Nove verze umi sifrovani obsahu databaze (nejen dat, jako driv, ale kompletni sifrovani DB). Takze i kdyz si to nekdo zkopiruje, bude mu to k nicemu. Jsou tam vykonostni dopady na procesor, ale nejsou nijak tragicke. Pokud delate opravdu nejake strategicke rizeni valky pro armadu, treba tohle bude cesta, kterou se ubirat.
Čo má byť účelom takého zabezpečenia? To sa snažíš o nejaký vendor lock-in? Pokiaľ máš v tej databáze naozaj nejaké dáta, ktoré nevlastní zákazník a chceš mu k nim zakázať priamy prístup, tak tie dáta nesmú byť umiestnené u zákazníka.
Dakujem za reakcie.
Ano, potrebujem zabranit, aby data boli modifikovane mimo oficialneho sw. A tiez, aby nemohli byt exportovane mimo tohto sw.
Skoda, ze db samotna sa neda zabezpecit heslom ale len db server.
Zabranit fyzickemu pristupu ku servrom je nemozne, zakaznik na to kasle /su sice v racku, ale pocas smeny tam moze prist ktokolvek a nik si to nevsimne, 12 hodinove smeny, na prevadzke niekedy len jeden zamestnanec/. A tiez zakaznik moze mat roznu 'potrebu' citat surove data a robit nejake vystupy mimo oficialneho sw.
Takze cela otazka smerovala hlavne k tomu, aby sa nedalo jednoducho dostat k datam, nielen modifikovat ale vobec ani citat. Lebo kto ma motivaciu, vsak to pozname...
To riesenie so sifrovanim je uz mozno komplikacia.
Jednak tam zrejme este pobezi aj SQL express 2008, minimalne na strojoch co maju este XP,
A tiez neviem na akej urovni sa to sifruje. Ak sa pripojim ja cez Sql management studio, tak uvidim co, sifrovane data?
Se správným heslem uvidíš samozřejmě nešifrovaná data.
Neuvidis. Krome prihlasovaciho jmena a hesla potrebujes i sifrovaci klic. Takze ani admin, ktery muze provadet zalohu se k datum nedostane
v express edíciách uvidíš,to o čom uvažuješ Ty,sa dá prevádzať len v plnohodnotnom SQL Serveri,nie v Express edíciách,kde je zabezpečenie len rudimentárne,to je jeden z dôvodov,pre ktoré sú poskytované zdarma.....staré express edície nešifrujú databázy vôbec-všetci oprávnení videli a mohli meniť všetko,v posledných je to len na úrovni práve prihláseného užívatela a ešte je to osekané na spustenie len jednej jedinej inštancie s jedným local user,u starších edícií sa dalo spustiť max 5 inštancií s nt admin,sever admin a 5 local user......v skratke Express edície sú naprosto nevhodné na nejaké "ostré" nasadenie v praxi,sú vhodné len na testovanie počas hrania sa s visual studiom a naučenie sa/zvyknutie si s tým nejako pracovať......
Jestli má Express nebo ne, to nesdělil.
Jinak nesouhlasím s tím, že express edice jsou dobré pouze na testování. Jsou vhodné tam, kde zákazníkovi stačí to, co express edice nabízí - omezenou velikost, omezený souběžný přístup, chybějící analytické nástroje. Na druhou stranu spousta aplikací používá DB jen jako úložiště dat a v takovém případě je express edice naprosto dostatečná a navíc zdarma.
Při změně podmínek placení SQL serveru na základě počtu jader je plnohodnotná verze docela drahý špás.
Ano, bude sa pouzivat len Express edicia. Kvoli cene. Zakaznik by plny server nikdy nezaplatil. Nebude tam nejake kvantum dat, obmedzenie na 1GB RAM a 10GB na velkost DB myslim plne postacuje. Ani klientov tam nebude pripojenych nejake kvantum, priemerne 4 pc na jeden server (vynimocne potom max.8). Ani tych dat nebudu zapisovat nejak moc, mozno 25 tabuliek a 500-3000 zaznamov denne.
Co sa tyka tej ochrany, zrejme najjednoduchsie bude zakodovat najcitlivejsie veci na urovni aplikacie a do db ukladat uz sifrovane data. Asi len najdolezitejsie veci, tak aby nebol ovplyvneny vykon.
Mohol by si to prosim trochu viac upresnit?
Šifrovaním dát na aplikačnej úrovni prichádzaš o možnosti, ktoré ti databáza za normálnych okolností poskytuje. Čiže nebudeš vedieť v tých dátach efektívne vyhľadávať, filtrovať podľa nich, a podobne. Neviem, či ťa to nejako obmedzí, pretože to závisí od konkrétnych detailov, že čo chceš vlastne šifrovať.
Najjednoduchšie by bolo umiestniť dáta, ku ktorým zákazník nemá mať prístup, na svoj vlastný server, a vystaviť ich von cez webovú službu. Ešte jednoduchšie by bolo podpísať so zákazníkom takú zmluvu, v ktorej sa stanoví, v akom rozsahu môže pracovať s poskytnutými dátami.
Ináč celá tá požiadavka na dodatočné šifrovanie je hodne neštandardná. Pochybujem, že to je niečo, čo by zákazník od vás požadoval. Mám z toho skôr pocit, že ste zákazníkovi predali niečo, čo mu vlastne ani nechcete dať. Riešiť to potom takto vám síce zabezpečí, že sa bude zákazníkovi od vás odchádzať síce ťažšie, ale s o to väčšou radosťou. Okrem toho si tým zbytočne sami komplikujete vývoj a údržbu toho systému. Je otázne, či vám to za to stojí.
Další věc je ta, že data patří zákazníkovi (jím pořízená data).
Šifrování, ať už DB nebo sloupců má význam tam, kde data obsahují citlivé (např. osobní) údaje, ke kterým by se neměl dostat kdejaký hejhula, který se k DB připojí.
Nechápu zákazníka, který umožní komukoliv přístup do serverovny nebo dokonce fyzicky k serveru.
Pokud opravdu kdokoli může k serveru, pak situace ani čisté řešení nemá.
Data sice patří zákazníkovi, ale pokud je někdo umí změnit mimo sw rozhraní (třeba umí SQL a umí se přihlásit), pak se může zákazník se sw firmou začít hádat, jaktože je narušená logická konzistence, jaktože nebyly ošetřeny vstupy apod...
Pokud se umí někdo mimo SW přihlásit tak, že se fyzicky přihlási na server jako admin a tam si v management studiu vytahuje data, pak to nemá s logickou konzistencí SW nic společného, ale je to prostě nezabezpečený přístup k serveru.
Pokud se přihlásí např. management studiem přes síť, pak se musel dostat k přihlašovacím údajům k SQL serveru (službě) a to taky nemá nic společného s logickou konzistencí SW.
Myslel jsem logickou konzistenci databáze. Např. když umažu hlavičku faktury a ponechám položky.
Tohle musí být jednoznačně ošetřené ve smlouvě s dodavatelem. Pokud bude zákazník sahat do dat (měnit), pak dodavatel za obsah dat nemůže ručit. A nemusí to být jen vazby mezi tabulkami, protoze constrainty vse osetrit nejde.
Presne toto som myslel, nejaky znamy nejakeho zamestnanca tam zacne vrtat a menit nejake data. Bud v prospech toho zamestnanca alebo v umysle poskodit.
Tiez tam budu osobne data.
to JF:
S tym nemam ziadny problem, kludne ich zakaznikovi vyexportujem, bud do uzivatelskych zostav alebo v nejakom surovom stave ako len bude chciet. Ale aby sa zakaznik mohol vrtat priamo v DB /aj ked su to jeho data/, alebo aby cital data priamo z DB mi je proti srsti.
To mas napriklad ako s autom - predaju ti ho, je to tvoj majetok, ale ziadny vyrobca ti normalne nedovoli vrtat sa v SW toho auta. Bud sa to neda vobec alebo to robi v obmedzenej miere servis.
Fakt skoda, ze koncepcia tej db neumoznuje z principu ochranu heslom, ale ze je to len pre cely db server. No nic, budeme s tym musiet zit.
Diky vsetkym za rady.
To ti ale nedovolí jenom smluvně. Prakticky tě v tom nemůže nijak omezit.
V tom případě si můžeš důležité záznamy v tabulce zabezpečit dalším sloupcem a nějakým hashem z několika sloupců.
Jakmile se něco změní, tak to poznáš.
V případě spuštění programu provedeš kontrolu, jakmile zjistíš, že něco nesedí, oznámíš to a odmítneš program sputit. Zásah (oprava) bude za peníze.
Další možnost je nasazení triggeru a veškeré změny dat zaznamenávat do další tabulky. Takže uvidíš, pokud se tam někdo vrtal a co přesně změnil.
Možností je víc, ve tvém případě bych zvolil první možnost. Po několika servisních zásazích to toho člověka přejde.