Ang pangalan ko ay Denis Rozhkov, ako ang pinuno ng pagbuo ng software sa kumpanya ng Gazinformservice, sa pangkat ng produkto . Ang batas at mga regulasyon ng korporasyon ay nagpapataw ng ilang mga kinakailangan para sa seguridad ng pag-iimbak ng data. Walang gustong makakuha ng access ang mga third party sa kumpidensyal na impormasyon, kaya mahalaga ang mga sumusunod na isyu para sa anumang proyekto: pagkilala at pagpapatunay, pamamahala ng access sa data, pagtiyak ng integridad ng impormasyon sa system, pag-log ng mga kaganapan sa seguridad. Samakatuwid, nais kong pag-usapan ang ilang mga kagiliw-giliw na punto tungkol sa seguridad ng DBMS.
Ang artikulo ay inihanda batay sa isang talumpati sa organisado . Kung ayaw mong basahin, maaari mong panoorin ang:
Ang artikulo ay magkakaroon ng tatlong bahagi:
- Paano i-secure ang mga koneksyon.
- Ano ang isang pag-audit ng mga aksyon at kung paano itala kung ano ang nangyayari sa gilid ng database at pagkonekta dito.
- Paano protektahan ang data sa database mismo at kung anong mga teknolohiya ang magagamit para dito.
Tatlong bahagi ng seguridad ng DBMS: proteksyon ng koneksyon, pag-audit ng aktibidad at proteksyon ng data
Pag-secure ng iyong mga koneksyon
Maaari kang kumonekta sa database nang direkta o hindi direkta sa pamamagitan ng mga web application. Bilang isang patakaran, ang gumagamit ng negosyo, iyon ay, ang taong nagtatrabaho sa DBMS, ay hindi direktang nakikipag-ugnayan dito.
Bago pag-usapan ang tungkol sa pagprotekta sa mga koneksyon, kailangan mong sagutin ang mahahalagang tanong na tumutukoy kung paano gagawin ang mga hakbang sa seguridad:
- Katumbas ba ang isang user ng negosyo sa isang user ng DBMS?
- kung ang pag-access sa data ng DBMS ay ibinibigay lamang sa pamamagitan ng isang API na kinokontrol mo, o kung ang mga talahanayan ay direktang ina-access;
- kung ang DBMS ay inilalaan sa isang hiwalay na protektadong segment, kung sino ang nakikipag-ugnayan dito at kung paano;
- kung ang pooling/proxy at mga intermediate na layer ay ginagamit, na maaaring magbago ng impormasyon tungkol sa kung paano binuo ang koneksyon at kung sino ang gumagamit ng database.
Ngayon tingnan natin kung anong mga tool ang maaaring gamitin upang ma-secure ang mga koneksyon:
- Gumamit ng mga solusyon sa klase ng firewall ng database. Ang karagdagang layer ng proteksyon, sa pinakamababa, ay magpapalaki sa transparency ng kung ano ang nangyayari sa DBMS, at sa maximum, makakapagbigay ka ng karagdagang proteksyon ng data.
- Gamitin ang mga patakaran sa password. Ang kanilang paggamit ay depende sa kung paano binuo ang iyong arkitektura. Sa anumang kaso, ang isang password sa configuration file ng isang web application na kumokonekta sa DBMS ay hindi sapat para sa proteksyon. Mayroong ilang mga tool sa DBMS na nagbibigay-daan sa iyong kontrolin na ang user at password ay nangangailangan ng pag-update.
Maaari kang magbasa nang higit pa tungkol sa mga function ng rating ng user , maaari mo ring malaman ang tungkol sa MS SQL Vulnerability Assessmen .
- Pagyamanin ang konteksto ng sesyon gamit ang kinakailangang impormasyon. Kung ang session ay malabo, hindi mo naiintindihan kung sino ang nagtatrabaho sa DBMS sa loob ng balangkas nito, maaari kang, sa loob ng balangkas ng operasyon na ginagawa, magdagdag ng impormasyon tungkol sa kung sino ang gumagawa ng ano at bakit. Ang impormasyong ito ay makikita sa pag-audit.
- I-configure ang SSL kung wala kang network separation sa pagitan ng DBMS at end user; wala ito sa isang hiwalay na VLAN. Sa ganitong mga kaso, kinakailangang protektahan ang channel sa pagitan ng consumer at ng DBMS mismo. Available din ang mga tool sa seguridad sa open source.
Paano ito makakaapekto sa pagganap ng DBMS?
Tingnan natin ang halimbawa ng PostgreSQL upang makita kung paano naaapektuhan ng SSL ang pag-load ng CPU, pinapataas ang mga timing at binabawasan ang TPS, at kung kakainin ba nito ang napakaraming mapagkukunan kung paganahin mo ito.
Ang paglo-load ng PostgreSQL gamit ang pgbench ay isang simpleng programa para sa pagpapatakbo ng mga pagsubok sa pagganap. Ito ay nagpapatupad ng isang solong pagkakasunud-sunod ng mga utos nang paulit-ulit, posibleng sa parallel database session, at pagkatapos ay kinakalkula ang average na rate ng transaksyon.
Subukan ang 1 nang walang SSL at gumagamit ng SSL — ang koneksyon ay itinatag para sa bawat transaksyon:
pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"vs
pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Subukan ang 2 nang walang SSL at gumagamit ng SSL — lahat ng mga transaksyon ay isinasagawa sa isang koneksyon:
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"vs
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Iba pang mga setting:
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000Mga resulta ng pagsubok:
WALANG SSL
SSL
Ang isang koneksyon ay itinatag para sa bawat transaksyon
average ng latency
171.915 ms
187.695 ms
tps kasama ang mga koneksyon sa pagtatatag
58.168112
53.278062
tps hindi kasama ang mga koneksyon sa pagtatatag
64.084546
58.725846
CPU
24%
28%
Ang lahat ng mga transaksyon ay isinasagawa sa isang koneksyon
average ng latency
6.722 ms
6.342 ms
tps kasama ang mga koneksyon sa pagtatatag
1587.657278
1576.792883
tps hindi kasama ang mga koneksyon sa pagtatatag
1588.380574
1577.694766
CPU
17%
21%
Sa magaan na pagkarga, ang impluwensya ng SSL ay maihahambing sa error sa pagsukat. Kung ang halaga ng data na inilipat ay napakalaki, ang sitwasyon ay maaaring iba. Kung magtatatag kami ng isang koneksyon sa bawat transaksyon (ito ay bihira, kadalasan ang koneksyon ay ibinabahagi sa pagitan ng mga user), mayroon kang malaking bilang ng mga koneksyon/disconnection, ang epekto ay maaaring mas malaki ng kaunti. Iyon ay, maaaring may mga panganib ng pagbaba ng pagganap, gayunpaman, ang pagkakaiba ay hindi masyadong malaki bilang hindi gumamit ng proteksyon.
Pakitandaan na may malaking pagkakaiba kung ihahambing mo ang mga operating mode: nagtatrabaho ka sa loob ng parehong session o sa iba't ibang session. Ito ay naiintindihan: ang mga mapagkukunan ay ginugol sa paggawa ng bawat koneksyon.
Nagkaroon kami ng kaso nang ikinonekta namin ang Zabbix sa trust mode, iyon ay, hindi nasuri ang md5, hindi na kailangan para sa pagpapatunay. Pagkatapos ay hiniling ng customer na paganahin ang md5 authentication mode. Naglagay ito ng mabigat na pagkarga sa CPU, at bumaba ang pagganap. Nagsimula kaming maghanap ng mga paraan para mag-optimize. Ang isa sa mga posibleng solusyon sa problema ay ang pagpapatupad ng mga paghihigpit sa network, gumawa ng hiwalay na mga VLAN para sa DBMS, magdagdag ng mga setting para malinaw kung sino ang kumukonekta mula sa kung saan at alisin ang pagpapatunay. Maaari mo ring i-optimize ang mga setting ng pagpapatotoo upang mabawasan ang mga gastos kapag pinapagana ang pagpapatunay, ngunit sa pangkalahatan ang paggamit ng iba't ibang mga pamamaraan ng pagpapatunay ay nakakaapekto sa pagganap at nangangailangan ng pagsasaalang-alang sa mga salik na ito kapag nagdidisenyo ng kapangyarihan sa pag-compute ng mga server (hardware) para sa DBMS.
Konklusyon: sa isang bilang ng mga solusyon, kahit na ang mga maliliit na nuances sa pagpapatunay ay maaaring makaapekto nang malaki sa proyekto at ito ay masama kapag ito ay nagiging malinaw lamang kapag ipinatupad sa produksyon.
Pag-audit ng aksyon
Ang pag-audit ay maaaring hindi lamang DBMS. Ang pag-audit ay tungkol sa pagkuha ng impormasyon tungkol sa kung ano ang nangyayari sa iba't ibang mga segment. Ito ay maaaring alinman sa isang database firewall o ang operating system kung saan ang DBMS ay binuo.
Sa komersyal na Enterprise level DBMSs lahat ay maayos sa pag-audit, ngunit sa open source - hindi palaging. Narito kung ano ang mayroon ang PostgreSQL:
- default na log - built-in na pag-log;
- mga extension: pgaudit - kung ang default na pag-log ay hindi sapat para sa iyo, maaari kang gumamit ng hiwalay na mga setting na lumulutas ng ilang mga problema.
Dagdag sa ulat sa video:
"Ang pangunahing pahayag na pag-log ay maaaring ibigay ng isang karaniwang pasilidad sa pag-log na may log_statement = lahat.
Ito ay katanggap-tanggap para sa pagsubaybay at iba pang paggamit, ngunit hindi nagbibigay ng antas ng detalyeng karaniwang kinakailangan para sa pag-audit.
Hindi sapat na magkaroon ng isang listahan ng lahat ng mga operasyon na isinagawa sa database.
Posible rin na makahanap ng mga tiyak na pahayag na interesado sa auditor.
Ang karaniwang pag-log ay nagpapakita kung ano ang hiniling ng user, habang ang pgAudit ay nakatuon sa mga detalye ng kung ano ang nangyari noong ang database ay nagsagawa ng query.
Halimbawa, maaaring gusto ng auditor na i-verify na ang isang partikular na talahanayan ay ginawa sa loob ng isang nakadokumentong window ng pagpapanatili.
Ito ay maaaring mukhang isang simpleng gawain na may pangunahing pag-audit at grep, ngunit paano kung ipinakita sa iyo ang isang bagay na tulad nito (sinasadyang nakalilito) halimbawa:
GAWIN $$
BEGIN
IPATAWAT ANG 'GUMAWA NG PAG-import ng TABLE' || 'ant_table(id int)';
WAKAS$$;
Ang karaniwang pag-log ay magbibigay sa iyo nito:
LOG: pahayag: DO $$
BEGIN
IPATAWAT ANG 'GUMAWA NG PAG-import ng TABLE' || 'ant_table(id int)';
WAKAS$$;
Lumilitaw na ang paghahanap ng talahanayan ng interes ay maaaring mangailangan ng ilang kaalaman sa code sa mga kaso kung saan ang mga talahanayan ay dynamic na nilikha.
Hindi ito mainam, dahil mas mainam na maghanap lamang ayon sa pangalan ng talahanayan.
Dito nagagamit ang pgAudit.
Para sa parehong input, gagawa ito ng output sa log:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGIN
IPATAWAT ANG 'GUMAWA NG PAG-import ng TABLE' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION,33,2,DDL,GUMAWA NG TABLE,TABLE,public.important_table,GUMAWA NG TABLE important_table (id INT)
Hindi lamang ang DO block ang naka-log, kundi pati na rin ang buong teksto ng CREATE TABLE na may uri ng pahayag, uri ng bagay, at buong pangalan, na nagpapadali sa paghahanap.
Kapag nagla-log ng SELECT at DML na mga pahayag, maaaring i-configure ang pgAudit upang mag-log ng hiwalay na entry para sa bawat relasyon na isinangguni sa statement.
Walang kinakailangang pag-parse upang mahanap ang lahat ng mga pahayag na humipo sa isang partikular na talahanayan() ».
Paano ito makakaapekto sa pagganap ng DBMS?
Magsagawa tayo ng mga pagsubok na may ganap na pag-audit na pinagana at tingnan kung ano ang mangyayari sa pagganap ng PostgreSQL. Paganahin natin ang maximum na pag-log sa database para sa lahat ng mga parameter.
Halos wala kaming binago sa configuration file, ang pinakamahalagang bagay ay i-on ang debug5 mode para makakuha ng maximum na impormasyon.
postgresql.conf
log_destination = 'stderr'
logging_collector = naka-on
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = naka-on
debug_print_rewritten = naka-on
debug_print_plan = naka-on
debug_pretty_print = naka-on
log_checkpoints = naka-on
log_connections = naka-on
log_disconnections = naka-on
log_duration = sa
log_hostname = naka-on
log_lock_waits = naka-on
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Europa/Moscow'
Sa isang PostgreSQL DBMS na may mga parameter ng 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, nagsasagawa kami ng tatlong pagsubok sa pag-load gamit ang mga utos:
$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmarkMga resulta ng pagsubok:
Walang pag-log
Sa pag-log
Kabuuang oras ng pagpuno ng database
43,74 sec
53,23 sec
Ram
24%
40%
CPU
72%
91%
Pagsubok 1 (50 koneksyon)
Bilang ng mga transaksyon sa loob ng 10 minuto
74169
32445
Mga transaksyon/seg
123
54
Average na Latency
405 ms
925 ms
Pagsubok 2 (150 koneksyon na may 100 posible)
Bilang ng mga transaksyon sa loob ng 10 minuto
81727
31429
Mga transaksyon/seg
136
52
Average na Latency
550 ms
1432 ms
Tungkol sa mga sukat
Laki ng DB
2251 MB
2262 MB
Laki ng log ng database
0 MB
4587 MB
Bottom line: ang isang buong pag-audit ay hindi napakahusay. Ang data mula sa pag-audit ay magiging kasing laki ng data sa mismong database, o higit pa. Ang dami ng pag-log na nabuo kapag nagtatrabaho sa isang DBMS ay isang karaniwang problema sa produksyon.
Tingnan natin ang iba pang mga parameter:
- Ang bilis ay hindi gaanong nagbabago: nang walang pag-log - 43,74 segundo, na may pag-log - 53,23 segundo.
- Ang pagganap ng RAM at CPU ay magdurusa, dahil kailangan mong bumuo ng isang audit file. Ito ay kapansin-pansin din sa pagiging produktibo.
Habang tumataas ang bilang ng mga koneksyon, natural, ang pagganap ay bahagyang lumala.
Sa mga korporasyong may audit ay mas mahirap:
- mayroong maraming data;
- kailangan ang pag-audit hindi lamang sa pamamagitan ng syslog sa SIEM, kundi pati na rin sa mga file: kung may mangyari sa syslog, dapat mayroong isang file na malapit sa database kung saan nai-save ang data;
- isang hiwalay na istante ang kailangan para sa pag-audit upang hindi masayang ang mga I/O disk, dahil ito ay tumatagal ng maraming espasyo;
- Nangyayari na ang mga empleyado ng seguridad ng impormasyon ay nangangailangan ng mga pamantayan ng GOST sa lahat ng dako, nangangailangan sila ng pagkakakilanlan ng estado.
Paghihigpit sa pag-access sa data
Tingnan natin ang mga teknolohiyang ginagamit upang protektahan ang data at i-access ito sa mga komersyal na DBMS at open source.
Ano ang karaniwang magagamit mo:
- Pag-encrypt at obfuscation ng mga pamamaraan at function (Wrapping) - iyon ay, hiwalay na mga tool at utility na ginagawang hindi nababasa ang nababasa na code. Totoo, hindi na ito mababago o maibabalik. Ang diskarte na ito kung minsan ay kinakailangan kahit sa panig ng DBMS - ang lohika ng mga paghihigpit sa lisensya o lohika ng awtorisasyon ay tiyak na naka-encrypt sa antas ng pamamaraan at pag-andar.
- Ang paglilimita sa visibility ng data sa pamamagitan ng mga row (RLS) ay kapag ang iba't ibang user ay nakakita ng isang table, ngunit ibang komposisyon ng mga row dito, iyon ay, isang bagay ay hindi maaaring ipakita sa isang tao sa row level.
- Ang pag-edit sa ipinapakitang data (Masking) ay kapag ang mga user sa isang column ng talahanayan ay nakakita ng alinman sa data o mga asterisk lang, iyon ay, para sa ilang mga user ang impormasyon ay isasara. Tinutukoy ng teknolohiya kung aling user ang ipinapakita kung ano batay sa kanilang antas ng pag-access.
- Seguridad DBA/Application DBA/DBA access control ay, sa halip, tungkol sa paghihigpit sa pag-access sa DBMS mismo, iyon ay, ang mga empleyado ng seguridad ng impormasyon ay maaaring ihiwalay mula sa mga administrator ng database at mga administrator ng application. Kaunti lang ang mga ganitong teknolohiya sa open source, ngunit marami ang mga ito sa mga komersyal na DBMS. Kailangan ang mga ito kapag maraming user na may access sa mga server mismo.
- Paghihigpit sa pag-access sa mga file sa antas ng file system. Maaari kang magbigay ng mga karapatan at mga pribilehiyo sa pag-access sa mga direktoryo upang ang bawat administrator ay may access lamang sa kinakailangang data.
- Mandatory access at memory clearing - ang mga teknolohiyang ito ay bihirang ginagamit.
- Ang end-to-end encryption na direkta mula sa DBMS ay client-side encryption na may pangunahing pamamahala sa server side.
- Data Encryption. Halimbawa, ang columnar encryption ay kapag gumamit ka ng mekanismo na nag-e-encrypt ng isang column ng database.
Paano ito nakakaapekto sa pagganap ng DBMS?
Tingnan natin ang halimbawa ng columnar encryption sa PostgreSQL. Mayroong isang module ng pgcrypto, pinapayagan ka nitong mag-imbak ng mga napiling field sa naka-encrypt na form. Ito ay kapaki-pakinabang kapag ang ilang data lamang ang mahalaga. Upang basahin ang mga naka-encrypt na field, ang kliyente ay nagpapadala ng isang decryption key, ang server ay nagde-decrypt ng data at ibinabalik ito sa kliyente. Kung wala ang susi, walang makakagawa ng anuman sa iyong data.
Subukan natin sa pgcrypto. Gumawa tayo ng table na may naka-encrypt na data at regular na data. Nasa ibaba ang mga utos para sa paglikha ng mga talahanayan, sa pinakaunang linya mayroong isang kapaki-pakinabang na utos - ang paglikha ng extension mismo sa pagpaparehistro ng DBMS:
CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));Susunod, subukan nating gumawa ng sample ng data mula sa bawat talahanayan at tingnan ang mga timing ng pagpapatupad.
Pagpili mula sa isang talahanayan na walang function ng pag-encrypt:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtNaka-on ang stopwatch.
id | teksto1 | teksto2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 linya)
Oras: 1,386 ms
Pagpili mula sa isang talahanayan na may function na pag-encrypt:
psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txtNaka-on ang stopwatch.
id | i-decrypt | i-decrypt
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 linya)
Oras: 50,203 ms
Mga resulta ng pagsubok:
Nang walang pag-encrypt
Pgcrypto (decrypt)
Sample ng 1000 row
1,386 ms
50,203 ms
CPU
15%
35%
Ram
+ 5%
Ang pag-encrypt ay may malaking epekto sa pagganap. Makikita na tumaas ang tiyempo, dahil ang mga pagpapatakbo ng pag-decryption ng naka-encrypt na data (at ang decryption ay karaniwang nakabalot pa rin sa iyong lohika) ay nangangailangan ng makabuluhang mapagkukunan. Iyon ay, ang ideya ng pag-encrypt ng lahat ng mga column na naglalaman ng ilang data ay puno ng pagbaba sa pagganap.
Gayunpaman, ang pag-encrypt ay hindi isang pilak na bala na lumulutas sa lahat ng mga problema. Ang decrypted data at ang decryption key sa panahon ng proseso ng pag-decrypting at pagpapadala ng data ay matatagpuan sa server. Samakatuwid, ang mga susi ay maaaring ma-intercept ng isang taong may ganap na access sa database server, tulad ng isang system administrator.
Kapag mayroong isang susi para sa buong column para sa lahat ng user (kahit na hindi para sa lahat, ngunit para sa mga kliyente ng isang limitadong hanay), hindi ito palaging mabuti at tama. Iyon ang dahilan kung bakit nagsimula silang gumawa ng end-to-end na pag-encrypt, sa DBMS sinimulan nilang isaalang-alang ang mga opsyon para sa pag-encrypt ng data sa panig ng kliyente at server, at ang parehong mga key-vault na imbakan ay lumitaw - hiwalay na mga produkto na nagbibigay ng pangunahing pamamahala sa DBMS gilid.
Mga tampok ng seguridad sa komersyal at open source na DBMS
Pag-andar
Uri
Patakaran sa Password
Pagtutuos ng kuwenta
Pagprotekta sa source code ng mga pamamaraan at pag-andar
RLS
Encryption
Orakulo
komersyal
+
+
+
+
+
MsSql
komersyal
+
+
+
+
+
komersyal
+
+
+
+
mga extension
PostgreSQL
Libre
mga extension
mga extension
-
+
mga extension
MongoDb
Libre
-
+
-
-
Available lang sa MongoDB Enterprise
Ang talahanayan ay malayo sa kumpleto, ngunit ang sitwasyon ay ito: sa mga komersyal na produkto, ang mga problema sa seguridad ay nalutas nang mahabang panahon, sa open source, bilang panuntunan, ang ilang uri ng mga add-on ay ginagamit para sa seguridad, maraming mga pag-andar ang nawawala. , minsan kailangan mong magdagdag ng isang bagay. Halimbawa, ang mga patakaran sa password - Ang PostgreSQL ay may maraming iba't ibang mga extension (, , , , ), na nagpapatupad ng mga patakaran sa password, ngunit, sa aking opinyon, wala sa mga ito ang sumasaklaw sa lahat ng pangangailangan ng domestic corporate segment.
Ano ang gagawin kung wala kang kailangan kahit saan? Halimbawa, gusto mong gumamit ng partikular na DBMS na walang mga function na kinakailangan ng customer.
Pagkatapos ay maaari kang gumamit ng mga solusyon sa third-party na gumagana sa iba't ibang DBMS, halimbawa, Crypto DB o Garda DB. Kung pinag-uusapan natin ang tungkol sa mga solusyon mula sa domestic segment, alam nila ang tungkol sa mga GOST nang mas mahusay kaysa sa open source.
Ang pangalawang opsyon ay isulat kung ano ang kailangan mo sa iyong sarili, ipatupad ang pag-access ng data at pag-encrypt sa application sa antas ng pamamaraan. Totoo, ito ay magiging mas mahirap sa GOST. Ngunit sa pangkalahatan, maaari mong itago ang data kung kinakailangan, ilagay ito sa isang DBMS, pagkatapos ay kunin ito at i-decrypt ito kung kinakailangan, sa mismong antas ng aplikasyon. Kasabay nito, agad na isipin kung paano mo protektahan ang mga algorithm na ito sa application. Sa aming opinyon, dapat itong gawin sa antas ng DBMS, dahil ito ay gagana nang mas mabilis.
Ang ulat na ito ay unang ipinakita sa sa pamamagitan ng Mail.ru Cloud Solutions. Tingnan moiba pang mga pagtatanghal at mag-subscribe sa mga anunsyo ng kaganapan sa Telegram .
Ano pa ang mababasa sa paksa:
- .
- .
Pinagmulan: www.habr.com