Jina langu ni Denis Rozhkov, mimi ni mkuu wa maendeleo ya programu katika kampuni ya Gazinformservice, katika timu ya bidhaa. Jatoba. Sheria na kanuni za ushirika zinaweka mahitaji fulani kwa usalama wa hifadhi ya data. Hakuna mtu anayetaka wahusika wengine kupata habari za siri, kwa hivyo masuala yafuatayo ni muhimu kwa mradi wowote: kitambulisho na uthibitishaji, kudhibiti ufikiaji wa data, kuhakikisha uadilifu wa habari katika mfumo, kuweka matukio ya usalama. Kwa hivyo, nataka kuzungumza juu ya vidokezo kadhaa vya kupendeza kuhusu usalama wa DBMS.

Makala hiyo ilitayarishwa kwa kuzingatia hotuba katika @DatabasesMeetup, iliyopangwa Mail.ru Cloud Solutions. Ikiwa hutaki kusoma, unaweza kutazama:

Nakala hiyo itakuwa na sehemu tatu:

• Jinsi ya kulinda miunganisho.
• Ni nini ukaguzi wa vitendo na jinsi ya kurekodi kile kinachotokea kwenye upande wa hifadhidata na kuunganishwa nayo.
• Jinsi ya kulinda data katika hifadhidata yenyewe na ni teknolojia gani zinazopatikana kwa hili.

Vipengele vitatu vya usalama wa DBMS: ulinzi wa muunganisho, ukaguzi wa shughuli na ulinzi wa data

Kulinda miunganisho yako

Unaweza kuunganisha kwenye hifadhidata moja kwa moja au kwa njia isiyo ya moja kwa moja kupitia programu za wavuti. Kama sheria, mtumiaji wa biashara, ambayo ni, mtu anayefanya kazi na DBMS, anaingiliana nayo kwa njia isiyo ya moja kwa moja.

Kabla ya kuzungumza juu ya kulinda miunganisho, unahitaji kujibu maswali muhimu ambayo huamua jinsi hatua za usalama zitaundwa:

• Je, mtumiaji mmoja wa biashara ni sawa na mtumiaji mmoja wa DBMS?
• ikiwa ufikiaji wa data ya DBMS hutolewa tu kupitia API ambayo unadhibiti, au ikiwa majedwali yanafikiwa moja kwa moja;
• ikiwa DBMS imetengwa kwa sehemu tofauti iliyolindwa, nani huingiliana nayo na jinsi gani;
• ikiwa tabaka za kuunganisha/bakala na za kati zinatumika, ambazo zinaweza kubadilisha maelezo kuhusu jinsi muunganisho unavyoundwa na ni nani anayetumia hifadhidata.

Sasa hebu tuone ni zana gani zinaweza kutumika kupata miunganisho salama:

1. Tumia suluhisho za darasa la firewall za hifadhidata. Safu ya ziada ya ulinzi, kwa kiwango cha chini, itaongeza uwazi wa kile kinachotokea katika DBMS, na kwa kiwango cha juu, utaweza kutoa ulinzi wa ziada wa data.
2. Tumia sera za nenosiri. Matumizi yao inategemea jinsi usanifu wako umejengwa. Kwa hali yoyote, nenosiri moja katika faili ya usanidi wa programu ya wavuti inayounganishwa na DBMS haitoshi kwa ulinzi. Kuna idadi ya zana za DBMS zinazokuwezesha kudhibiti kwamba mtumiaji na nenosiri zinahitaji kusasishwa.

   Unaweza kusoma zaidi kuhusu vipengele vya ukadiriaji wa mtumiaji hapa, unaweza pia kujua kuhusu MS SQL Vulnerability Assessmen hapa. 

3. Boresha muktadha wa kikao kwa taarifa muhimu. Ikiwa kikao ni opaque, huelewi ni nani anayefanya kazi katika DBMS ndani ya mfumo wake, unaweza, ndani ya mfumo wa uendeshaji unaofanywa, kuongeza habari kuhusu nani anafanya nini na kwa nini. Habari hii inaweza kuonekana katika ukaguzi.
4. Sanidi SSL ikiwa huna utenganisho wa mtandao kati ya DBMS na watumiaji wa mwisho; haiko katika VLAN tofauti. Katika hali kama hizi, ni muhimu kulinda chaneli kati ya watumiaji na DBMS yenyewe. Zana za usalama zinapatikana pia katika chanzo huria.

Je, hii itaathiri vipi utendaji wa DBMS?

Wacha tuangalie mfano wa PostgreSQL ili kuona jinsi SSL inavyoathiri mzigo wa CPU, huongeza muda na kupunguza TPS, na ikiwa itatumia rasilimali nyingi ukiiwezesha.

Kupakia PostgreSQL kwa kutumia pgbench ni programu rahisi ya kufanya majaribio ya utendakazi. Hutekeleza mlolongo mmoja wa amri mara kwa mara, ikiwezekana katika vipindi sambamba vya hifadhidata, na kisha kukokotoa wastani wa kiwango cha ununuzi.

Jaribu 1 bila SSL na utumie SSL - muunganisho umeanzishwa kwa kila shughuli:

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"

Jaribu 2 bila SSL na utumie SSL - shughuli zote zinafanywa kwa unganisho moja:

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"

Mipangilio mingine:

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/50000

Matokeo ya mtihani:

 
HAKUNA SSL
SSL

Muunganisho umeanzishwa kwa kila shughuli

wastani wa latency
171.915 ms
187.695 ms

tps ikiwa ni pamoja na kuanzisha miunganisho
58.168112
53.278062

tps bila kujumuisha uanzishaji wa miunganisho
64.084546
58.725846

CPU
24%
28%

Shughuli zote zinafanywa kwa muunganisho mmoja

wastani wa latency
6.722 ms
6.342 ms

tps ikiwa ni pamoja na kuanzisha miunganisho
1587.657278
1576.792883

tps bila kujumuisha uanzishaji wa miunganisho
1588.380574
1577.694766

CPU
17%
21%

Katika mizigo nyepesi, ushawishi wa SSL unalinganishwa na kosa la kipimo. Ikiwa kiasi cha data iliyohamishwa ni kubwa sana, hali inaweza kuwa tofauti. Ikiwa tutaanzisha muunganisho mmoja kwa kila muamala (hii ni nadra, kwa kawaida muunganisho hushirikiwa kati ya watumiaji), una idadi kubwa ya miunganisho/mikato, athari inaweza kuwa kubwa kidogo. Hiyo ni, kunaweza kuwa na hatari za kupungua kwa utendaji, hata hivyo, tofauti sio kubwa sana kwa kutotumia ulinzi.

Tafadhali kumbuka kuwa kuna tofauti kubwa ikiwa unalinganisha njia za uendeshaji: unafanya kazi ndani ya kikao kimoja au kwa tofauti tofauti. Hii inaeleweka: rasilimali hutumiwa kuunda kila muunganisho.

Tulikuwa na kesi tulipounganisha Zabbix katika hali ya uaminifu, yaani, md5 haikuangaliwa, hakukuwa na haja ya uthibitishaji. Kisha mteja akaomba kuwezesha modi ya uthibitishaji ya md5. Hii iliweka mzigo mzito kwenye CPU, na utendaji ulishuka. Tulianza kutafuta njia za kuboresha. Mojawapo ya suluhisho zinazowezekana kwa tatizo ni kutekeleza vizuizi vya mtandao, kutengeneza VLAN tofauti kwa DBMS, kuongeza mipangilio ili kuweka wazi ni nani anayeunganisha kutoka wapi na kuondoa uthibitishaji. Unaweza pia kuboresha mipangilio ya uthibitishaji ili kupunguza gharama wakati wa kuwezesha uthibitishaji, lakini kwa ujumla matumizi ya mbinu tofauti uthibitishaji huathiri utendakazi na inahitaji kuzingatia mambo haya wakati wa kubuni nguvu za kompyuta za seva (vifaa) kwa DBMS.

Hitimisho: katika idadi ya ufumbuzi, hata nuances ndogo katika uthibitishaji inaweza kuathiri sana mradi na ni mbaya wakati hii inakuwa wazi tu wakati kutekelezwa katika uzalishaji.

Ukaguzi wa vitendo

Ukaguzi hauwezi kuwa DBMS pekee. Ukaguzi ni kuhusu kupata taarifa kuhusu kile kinachotokea katika sehemu mbalimbali. Hii inaweza kuwa firewall ya hifadhidata au mfumo wa uendeshaji ambao DBMS imejengwa.

Katika kiwango cha Biashara cha DBMS kila kitu kiko sawa na ukaguzi, lakini katika chanzo wazi - sio kila wakati. Hii ndio PostgreSQL inayo:

• logi ya msingi - ukataji wa kujengwa;
• upanuzi: pgaudit - ikiwa ukataji msingi haukutoshi, unaweza kutumia mipangilio tofauti ambayo husuluhisha shida kadhaa.

Nyongeza kwa ripoti kwenye video:

"Ukataji wa taarifa za kimsingi unaweza kutolewa na kituo cha kawaida cha ukataji miti na log_statement = yote.

Hii inakubalika kwa ufuatiliaji na matumizi mengine, lakini haitoi kiwango cha maelezo kinachohitajika kwa ukaguzi.

Haitoshi kuwa na orodha ya shughuli zote zilizofanywa kwenye hifadhidata.

Inapaswa pia kuwa inawezekana kupata taarifa maalum ambazo zinavutia mkaguzi.

Uwekaji kumbukumbu wa kawaida huonyesha kile ambacho mtumiaji aliomba, huku pgAudit inaangazia maelezo ya kile kilichotokea wakati hifadhidata ilipotekeleza hoja.

Kwa mfano, mkaguzi anaweza kutaka kuthibitisha kwamba jedwali fulani liliundwa ndani ya dirisha la matengenezo lililoandikwa.

Hii inaweza kuonekana kama kazi rahisi na ukaguzi wa kimsingi na grep, lakini vipi ikiwa utawasilishwa na kitu kama hiki (kinachochanganya kwa kukusudia):

DO$$
BEGIN
TIMIZA 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

Ukataji miti wa kawaida utakupa hii:

LOG: taarifa: FANYA $$
BEGIN
TIMIZA 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

Inaonekana kwamba kupata jedwali la maslahi kunaweza kuhitaji ujuzi fulani wa kanuni katika hali ambapo jedwali zinaundwa kwa nguvu.

Hii sio bora, kwani itakuwa vyema kutafuta tu kwa jina la jedwali.

Hapa ndipo pgAudit inakuja kwa manufaa.

Kwa pembejeo sawa, itatoa pato hili kwenye logi:

UKAGUZI: KIKAO,33,1,KAZI,FANYA,,,"FANYA $$
BEGIN
TIMIZA 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
UKAGUZI: KIKAO,33,2,DDL,CREATE TABLE,JEDWALI,public.muhimu_meza,UNDA JEDWALI_muhimu (ID)

Sio tu kizuizi cha DO kimeingia, lakini pia maandishi kamili ya CREATE TABLE yenye aina ya taarifa, aina ya kitu, na jina kamili, na kurahisisha utafutaji.

Wakati wa kuingia SELECT na taarifa za DML, pgAudit inaweza kusanidiwa ili kuweka ingizo tofauti kwa kila uhusiano unaorejelewa katika taarifa.

Hakuna uchanganuzi unaohitajika kupata taarifa zote zinazogusa jedwali fulani(*) ".

Je, hii itaathiri vipi utendaji wa DBMS?

Wacha tufanye majaribio na ukaguzi kamili umewezeshwa na tuone kinachotokea kwa utendaji wa PostgreSQL. Wacha tuwezeshe uwekaji kumbukumbu wa hifadhidata kwa vigezo vyote.

Hatubadilishi chochote katika faili ya usanidi, jambo muhimu zaidi ni kuwasha modi ya debug5 ili kupata habari ya juu.

postgresql.conf

log_destination = 'stderr'
logging_collector = imewashwa
log_truncate_on_rotation = imewashwa
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 = imewashwa
debug_print_rewritten = imewashwa
debug_print_plan = imewashwa
debug_pretty_print = imewashwa
log_checkpoints = imewashwa
log_connections = imewashwa
log_disconnections = imewashwa
log_duration = imewashwa
log_hostname = imewashwa
log_lock_wait = imewashwa
log_replication_commands = imewashwa
log_temp_files = 0
log_timezone = 'Ulaya/Moscow'

Kwenye PostgreSQL DBMS yenye vigezo vya 1 CPU, 2,8 GHz, RAM ya GB 2, HDD ya GB 40, tunafanya majaribio matatu ya upakiaji kwa kutumia amri:

$ 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 benchmark

Matokeo ya mtihani:

Hakuna ukataji miti
Pamoja na ukataji miti

Jumla ya muda wa kujaza hifadhidata
Dakika ya 43,74
Dakika ya 53,23

RAM
24%
40%

CPU
72%
91%

Jaribio la 1 (viunganisho 50)

Idadi ya miamala ndani ya dakika 10
74169
32445

Shughuli/sek
123
54

Wastani wa Kuchelewa
405 ms
925 ms

Jaribio la 2 (miunganisho 150 na 100 inawezekana)

Idadi ya miamala ndani ya dakika 10
81727
31429

Shughuli/sek
136
52

Wastani wa Kuchelewa
550 ms
1432 ms

Kuhusu saizi

Ukubwa wa DB
2251 MB
2262 MB

Saizi ya kumbukumbu ya hifadhidata
0 MB
4587 MB

Chini ya msingi: ukaguzi kamili sio mzuri sana. Data kutoka kwa ukaguzi itakuwa kubwa kama data katika hifadhidata yenyewe, au hata zaidi. Kiasi cha magogo ambayo huzalishwa wakati wa kufanya kazi na DBMS ni tatizo la kawaida katika uzalishaji.

Wacha tuangalie vigezo vingine:

• Kasi haibadilika sana: bila kukata magogo - sekunde 43,74, na ukataji miti - sekunde 53,23.
• Utendaji wa RAM na CPU utateseka, kwani unahitaji kutoa faili ya ukaguzi. Hii pia inaonekana katika tija.

Kadiri idadi ya viunganisho inavyoongezeka, kwa kawaida, utendaji utaharibika kidogo.

Katika mashirika yenye ukaguzi ni ngumu zaidi:

• kuna data nyingi;
• ukaguzi unahitajika sio tu kupitia syslog katika SIEM, lakini pia katika faili: ikiwa kitu kitatokea kwa syslog, lazima kuwe na faili karibu na hifadhidata ambayo data imehifadhiwa;
• rafu tofauti inahitajika kwa ukaguzi ili usipoteze disks za I / O, kwani inachukua nafasi nyingi;
• Inatokea kwamba wafanyikazi wa usalama wa habari wanahitaji viwango vya GOST kila mahali, wanahitaji kitambulisho cha serikali.

Kuzuia ufikiaji wa data

Hebu tuangalie teknolojia zinazotumika kulinda data na kuipata katika DBMS za kibiashara na chanzo huria.

Nini unaweza kutumia kwa ujumla:

1. Usimbaji fiche na ufiche wa taratibu na kazi (Ufungaji) - yaani, zana tofauti na huduma zinazofanya msimbo unaoweza kusomeka usisomeke. Kweli, basi haiwezi kubadilishwa au kurudishwa nyuma. Mbinu hii wakati mwingine inahitajika angalau kwa upande wa DBMS - mantiki ya vikwazo vya leseni au mantiki ya uidhinishaji imesimbwa kwa njia fiche kwa usahihi katika kiwango cha utaratibu na utendaji.
2. Kupunguza mwonekano wa data kwa safu mlalo (RLS) ni wakati watumiaji tofauti wanaona jedwali moja, lakini muundo tofauti wa safu mlalo ndani yake, yaani, kitu hakiwezi kuonyeshwa kwa mtu katika kiwango cha safu mlalo.
3. Kuhariri data iliyoonyeshwa (Masking) ni wakati watumiaji katika safu moja ya jedwali wanaona data au nyota tu, yaani, kwa watumiaji wengine habari itafungwa. Teknolojia huamua ni mtumiaji gani anaonyeshwa nini kulingana na kiwango cha ufikiaji.
4. Udhibiti wa ufikiaji wa DBA/Application DBA/DBA, badala yake, unahusu kuzuia ufikiaji wa DBMS yenyewe, yaani, wafanyikazi wa usalama wa habari wanaweza kutengwa na wasimamizi wa hifadhidata na wasimamizi wa programu. Kuna teknolojia chache kama hizo kwenye chanzo wazi, lakini kuna nyingi katika DBMS za kibiashara. Zinahitajika wakati kuna watumiaji wengi wenye ufikiaji wa seva zenyewe.
5. Kuzuia ufikiaji wa faili katika kiwango cha mfumo wa faili. Unaweza kutoa haki na upendeleo wa kufikia saraka ili kila msimamizi apate ufikiaji wa data muhimu pekee.
6. Ufikiaji wa lazima na kusafisha kumbukumbu - teknolojia hizi hazitumiwi sana.
7. Usimbaji fiche kutoka mwanzo hadi mwisho moja kwa moja kutoka kwa DBMS ni usimbaji fiche wa upande wa mteja na udhibiti muhimu kwenye upande wa seva.
8. Usimbaji fiche wa data. Kwa mfano, usimbaji fiche wa safu ni wakati unapotumia utaratibu unaosimba safu wima moja ya hifadhidata.

Je, hii inaathiri vipi utendaji wa DBMS?

Wacha tuangalie mfano wa usimbuaji wa safu katika PostgreSQL. Kuna moduli ya pgcrypto, hukuruhusu kuhifadhi sehemu zilizochaguliwa katika fomu iliyosimbwa. Hii ni muhimu wakati data fulani pekee ndiyo yenye thamani. Ili kusoma sehemu zilizosimbwa, mteja hutuma ufunguo wa usimbuaji, seva huondoa data na kuirudisha kwa mteja. Bila ufunguo, hakuna mtu anayeweza kufanya chochote na data yako.

Wacha tujaribu na pgcrypto. Wacha tuunde jedwali na data iliyosimbwa na data ya kawaida. Chini ni amri za kuunda meza, katika mstari wa kwanza kuna amri muhimu - kuunda ugani yenyewe na usajili wa 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'));

Ifuatayo, hebu tujaribu kutengeneza sampuli ya data kutoka kwa kila jedwali na tuangalie muda wa utekelezaji.

Kuchagua kutoka kwa jedwali bila kazi ya usimbaji fiche:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

Stopwatch imewashwa.

  kitambulisho | maandishi1 | maandishi2
——+———-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(mistari 1000)

Muda: 1,386 ms

Uteuzi kutoka kwa jedwali iliyo na kazi ya usimbuaji:

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

Stopwatch imewashwa.

  kitambulisho | simbua | kusimbua
——+——————+—————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(mistari 1000)

Muda: 50,203 ms

Matokeo ya mtihani:

 
Bila usimbaji fiche
Pgcrypto (simbua)

Sampuli ya safu 1000
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

Usimbaji fiche una athari kubwa kwenye utendaji. Inaweza kuonekana kuwa muda umeongezeka, kwani shughuli za usimbuaji wa data iliyosimbwa (na usimbaji fiche kawaida bado umefungwa katika mantiki yako) zinahitaji rasilimali muhimu. Hiyo ni, wazo la kusimba safu wima zote zilizo na data fulani limejaa kupungua kwa utendakazi.

Walakini, usimbuaji sio risasi ya fedha ambayo husuluhisha shida zote. Data iliyosimbwa na ufunguo wa usimbuaji wakati wa mchakato wa kusimbua na kusambaza data ziko kwenye seva. Kwa hivyo, funguo zinaweza kuzuiwa na mtu ambaye ana ufikiaji kamili wa seva ya hifadhidata, kama vile msimamizi wa mfumo.

Wakati kuna ufunguo mmoja kwa safu nzima kwa watumiaji wote (hata ikiwa si kwa wote, lakini kwa wateja wa seti ndogo), hii sio daima nzuri na sahihi. Ndio sababu walianza kufanya usimbuaji wa mwisho-hadi-mwisho, katika DBMS walianza kuzingatia chaguzi za usimbuaji data kwa mteja na upande wa seva, na hifadhi hizo hizo za ufunguo wa vault zilionekana - bidhaa tofauti ambazo hutoa usimamizi muhimu kwenye DBMS. upande.

Mfano wa usimbaji fiche kama huo katika MongoDB

Vipengele vya usalama katika DBMS ya kibiashara na ya wazi

Kazi
Aina
Sera ya Nenosiri
Ukaguzi
Kulinda kanuni ya chanzo cha taratibu na kazi
RLS
Encryption

Oracle
kibiashara
+
+
+
+
+

MsSql
kibiashara
+
+
+
+
+

Jatoba
kibiashara
+
+
+
+
upanuzi

PostgreSQL
Free
upanuzi
upanuzi
-
+
upanuzi

MongoDb
Free
-
+
-
-
Inapatikana katika MongoDB Enterprise pekee

Jedwali ni mbali na kukamilika, lakini hali ni hii: katika bidhaa za kibiashara, shida za usalama zimetatuliwa kwa muda mrefu, katika chanzo wazi, kama sheria, aina fulani ya nyongeza hutumiwa kwa usalama, kazi nyingi hazipo. , wakati mwingine lazima uongeze kitu. Kwa mfano, sera za nenosiri - PostgreSQL ina viendelezi vingi tofauti (1, 2, 3, 4, 5), ambayo hutekeleza sera za nenosiri, lakini, kwa maoni yangu, hakuna hata mmoja wao anayeshughulikia mahitaji yote ya sehemu ya ushirika wa ndani.

Nini cha kufanya ikiwa huna kile unachohitaji popote? Kwa mfano, unataka kutumia DBMS mahususi ambayo haina vitendaji ambavyo mteja anahitaji.

Kisha unaweza kutumia ufumbuzi wa tatu ambao hufanya kazi na DBMS tofauti, kwa mfano, Crypto DB au Garda DB. Ikiwa tunazungumzia juu ya ufumbuzi kutoka kwa sehemu ya ndani, basi wanajua kuhusu GOSTs bora kuliko katika chanzo wazi.

Chaguo la pili ni kuandika unachohitaji mwenyewe, kutekeleza ufikiaji wa data na usimbuaji fiche katika programu katika kiwango cha utaratibu. Kweli, itakuwa ngumu zaidi na GOST. Lakini kwa ujumla, unaweza kuficha data kama inahitajika, kuiweka kwenye DBMS, kisha kuipata na kuifuta kama inahitajika, kwenye kiwango cha maombi. Wakati huo huo, fikiria mara moja jinsi utakavyolinda algorithms hizi kwenye programu. Kwa maoni yetu, hii inapaswa kufanyika kwa kiwango cha DBMS, kwa sababu itafanya kazi kwa kasi zaidi.

Ripoti hii iliwasilishwa kwa mara ya kwanza @Mkutano wa Hifadhidata na Mail.ru Cloud Solutions. Tazama video maonyesho mengine na ujiandikishe kwa matangazo ya hafla kwenye Telegraph Karibu na Kubernetes kwenye Mail.ru Group.

Nini kingine cha kusoma kwenye mada:

1. Zaidi ya Ceph: Hifadhi ya kuzuia wingu ya MCS.
2. Jinsi ya kuchagua hifadhidata ya mradi ili sio lazima uchague tena.

Chanzo: mapenzi.com