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.
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ť......
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.