பாதுகாப்பு மற்றும் DBMS: பாதுகாப்புக் கருவிகளைத் தேர்ந்தெடுக்கும்போது நீங்கள் நினைவில் கொள்ள வேண்டியவை

பாதுகாப்பு மற்றும் DBMS: பாதுகாப்புக் கருவிகளைத் தேர்ந்தெடுக்கும்போது நீங்கள் நினைவில் கொள்ள வேண்டியவை

எனது பெயர் டெனிஸ் ரோஷ்கோவ், நான் தயாரிப்பு குழுவில் உள்ள Gazinformservice நிறுவனத்தில் மென்பொருள் மேம்பாட்டுத் தலைவராக இருக்கிறேன் ஜடோபா. சட்டம் மற்றும் கார்ப்பரேட் விதிமுறைகள் தரவு சேமிப்பகத்தின் பாதுகாப்பிற்கு சில தேவைகளை விதிக்கின்றன. மூன்றாம் தரப்பினர் ரகசியத் தகவலை அணுகுவதை யாரும் விரும்புவதில்லை, எனவே எந்தவொரு திட்டத்திற்கும் பின்வரும் சிக்கல்கள் முக்கியம்: அடையாளம் மற்றும் அங்கீகாரம், தரவு அணுகலை நிர்வகித்தல், கணினியில் உள்ள தகவலின் ஒருமைப்பாட்டை உறுதி செய்தல், பாதுகாப்பு நிகழ்வுகளை பதிவு செய்தல். எனவே, DBMS பாதுகாப்பு தொடர்பான சில சுவாரஸ்யமான விஷயங்களைப் பற்றி நான் பேச விரும்புகிறேன்.

இல் ஆற்றிய உரையின் அடிப்படையில் கட்டுரை தயாரிக்கப்பட்டது @DatabasesMeetup, ஏற்பாடு Mail.ru கிளவுட் தீர்வுகள். நீங்கள் படிக்க விரும்பவில்லை என்றால், நீங்கள் பார்க்கலாம்:


கட்டுரை மூன்று பகுதிகளைக் கொண்டிருக்கும்:

  • இணைப்புகளை எவ்வாறு பாதுகாப்பது.
  • செயல்களின் தணிக்கை என்றால் என்ன மற்றும் தரவுத்தள பக்கத்தில் என்ன நடக்கிறது மற்றும் அதனுடன் இணைப்பதை எவ்வாறு பதிவு செய்வது.
  • தரவுத்தளத்தில் உள்ள தரவை எவ்வாறு பாதுகாப்பது மற்றும் இதற்கு என்ன தொழில்நுட்பங்கள் உள்ளன.

பாதுகாப்பு மற்றும் DBMS: பாதுகாப்புக் கருவிகளைத் தேர்ந்தெடுக்கும்போது நீங்கள் நினைவில் கொள்ள வேண்டியவை
டிபிஎம்எஸ் பாதுகாப்பின் மூன்று கூறுகள்: இணைப்பு பாதுகாப்பு, செயல்பாட்டு தணிக்கை மற்றும் தரவு பாதுகாப்பு

உங்கள் இணைப்புகளைப் பாதுகாத்தல்

இணைய பயன்பாடுகள் மூலம் நேரடியாகவோ அல்லது மறைமுகமாகவோ தரவுத்தளத்துடன் இணைக்கலாம். ஒரு விதியாக, வணிக பயனர், அதாவது, DBMS உடன் பணிபுரியும் நபர், மறைமுகமாக அதனுடன் தொடர்பு கொள்கிறார்.

இணைப்புகளைப் பாதுகாப்பதைப் பற்றி பேசுவதற்கு முன், பாதுகாப்பு நடவடிக்கைகள் எவ்வாறு கட்டமைக்கப்படும் என்பதைத் தீர்மானிக்கும் முக்கியமான கேள்விகளுக்கு நீங்கள் பதிலளிக்க வேண்டும்:

  • ஒரு வணிகப் பயனர் ஒரு DBMS பயனருக்குச் சமமா?
  • நீங்கள் கட்டுப்படுத்தும் API மூலம் மட்டுமே DBMS தரவுக்கான அணுகல் வழங்கப்படுகிறதா அல்லது அட்டவணைகள் நேரடியாக அணுகப்படுகிறதா;
  • DBMS தனியான பாதுகாக்கப்பட்ட பிரிவுக்கு ஒதுக்கப்பட்டுள்ளதா, யார் அதனுடன் தொடர்பு கொள்கிறார்கள் மற்றும் எப்படி;
  • பூலிங்/ப்ராக்ஸி மற்றும் இடைநிலை அடுக்குகள் பயன்படுத்தப்படுகிறதா, இணைப்பு எவ்வாறு கட்டமைக்கப்பட்டுள்ளது மற்றும் தரவுத்தளத்தை யார் பயன்படுத்துகிறார்கள் என்பது பற்றிய தகவலை மாற்றலாம்.

இப்போது இணைப்புகளைப் பாதுகாக்க என்ன கருவிகளைப் பயன்படுத்தலாம் என்று பார்ப்போம்:

  1. தரவுத்தள ஃபயர்வால் வகுப்பு தீர்வுகளைப் பயன்படுத்தவும். கூடுதல் பாதுகாப்பு அடுக்கு, குறைந்தபட்சம், DBMS இல் என்ன நடக்கிறது என்பதன் வெளிப்படைத்தன்மையை அதிகரிக்கும், மேலும் அதிகபட்சமாக, நீங்கள் கூடுதல் தரவு பாதுகாப்பை வழங்க முடியும்.
  2. கடவுச்சொல் கொள்கைகளைப் பயன்படுத்தவும். அவற்றின் பயன்பாடு உங்கள் கட்டிடக்கலை எவ்வாறு கட்டமைக்கப்பட்டுள்ளது என்பதைப் பொறுத்தது. எவ்வாறாயினும், DBMS உடன் இணைக்கும் வலை பயன்பாட்டின் உள்ளமைவு கோப்பில் ஒரு கடவுச்சொல் பாதுகாப்புக்கு போதுமானதாக இல்லை. பயனர் மற்றும் கடவுச்சொல் புதுப்பிக்கப்படுவதைக் கட்டுப்படுத்த உங்களை அனுமதிக்கும் பல DBMS கருவிகள் உள்ளன.

    பயனர் மதிப்பீடு செயல்பாடுகளைப் பற்றி மேலும் படிக்கலாம் இங்கே, நீங்கள் MS SQL பாதிப்பு மதிப்பீட்டாளர்களைப் பற்றியும் அறியலாம் இங்கே

  3. தேவையான தகவல்களுடன் அமர்வின் சூழலை வளப்படுத்தவும். அமர்வு ஒளிபுகாதாக இருந்தால், DBMS இல் அதன் கட்டமைப்பிற்குள் யார் வேலை செய்கிறார்கள் என்பது உங்களுக்குப் புரியவில்லை, செய்யப்படும் செயல்பாட்டின் கட்டமைப்பிற்குள், யார் என்ன செய்கிறார்கள், ஏன் செய்கிறார்கள் என்பது பற்றிய தகவலைச் சேர்க்கலாம். இந்த தகவலை தணிக்கையில் காணலாம்.
  4. DBMS மற்றும் இறுதிப் பயனர்களுக்கு இடையே நெட்வொர்க் பிரிப்பு இல்லை என்றால் SSL ஐ உள்ளமைக்கவும்; அது தனி VLAN இல் இல்லை. இதுபோன்ற சந்தர்ப்பங்களில், நுகர்வோருக்கும் DBMS க்கும் இடையில் சேனலைப் பாதுகாக்க வேண்டியது அவசியம். பாதுகாப்பு கருவிகள் திறந்த மூலத்திலும் கிடைக்கின்றன.

இது DBMS இன் செயல்திறனை எவ்வாறு பாதிக்கும்?

PostgreSQL இன் எடுத்துக்காட்டைப் பார்ப்போம், SSL ஆனது CPU சுமையை எவ்வாறு பாதிக்கிறது, நேரத்தை அதிகரிக்கிறது மற்றும் TPS ஐக் குறைக்கிறது, மேலும் நீங்கள் அதை இயக்கினால் அது அதிக வளங்களைச் செலவழிக்குமா என்பதைப் பார்க்கலாம்.

Pgbench ஐப் பயன்படுத்தி PostgreSQL ஐ ஏற்றுவது செயல்திறன் சோதனைகளை இயக்குவதற்கான எளிய நிரலாகும். இது கட்டளைகளின் ஒற்றை வரிசையை மீண்டும் மீண்டும் செயல்படுத்துகிறது, ஒருவேளை இணையான தரவுத்தள அமர்வுகளில், பின்னர் சராசரி பரிவர்த்தனை விகிதத்தை கணக்கிடுகிறது.

SSL இல்லாமல் மற்றும் SSL ஐப் பயன்படுத்தி சோதனை 1 - ஒவ்வொரு பரிவர்த்தனைக்கும் இணைப்பு நிறுவப்பட்டுள்ளது:

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"

SSL இல்லாமல் மற்றும் SSL ஐப் பயன்படுத்தி சோதனை 2 - அனைத்து பரிவர்த்தனைகளும் ஒரே இணைப்பில் செய்யப்படுகின்றன:

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"

பிற அமைப்புகள்:

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

சோதனை முடிவுகள்:

 
SSL இல்லை
SSL ஐ

ஒவ்வொரு பரிவர்த்தனைக்கும் ஒரு இணைப்பு நிறுவப்பட்டுள்ளது

தாமத சராசரி
171.915 எம்எஸ்
187.695 எம்எஸ்

இணைப்புகளை நிறுவுதல் உட்பட tps
58.168112
53.278062

இணைப்புகளை நிறுவுவதைத் தவிர்த்து tps
64.084546
58.725846

சிபியு
24%
28%

அனைத்து பரிவர்த்தனைகளும் ஒரு இணைப்பில் செய்யப்படுகின்றன

தாமத சராசரி
6.722 எம்எஸ்
6.342 எம்எஸ்

இணைப்புகளை நிறுவுதல் உட்பட tps
1587.657278
1576.792883

இணைப்புகளை நிறுவுவதைத் தவிர்த்து tps
1588.380574
1577.694766

சிபியு
17%
21%

லேசான சுமைகளில், SSL இன் செல்வாக்கு அளவீட்டு பிழையுடன் ஒப்பிடத்தக்கது. பரிமாற்றப்பட்ட தரவு அளவு மிகப் பெரியதாக இருந்தால், நிலைமை வேறுபட்டிருக்கலாம். ஒரு பரிவர்த்தனைக்கு ஒரு இணைப்பை நாங்கள் நிறுவினால் (இது அரிதானது, பொதுவாக இணைப்பு பயனர்களிடையே பகிரப்படும்), உங்களிடம் அதிக எண்ணிக்கையிலான இணைப்புகள்/துண்டிப்புகள் உள்ளன, இதன் தாக்கம் சற்று அதிகமாக இருக்கலாம். அதாவது, செயல்திறன் குறைவதற்கான அபாயங்கள் இருக்கலாம், இருப்பினும், பாதுகாப்பைப் பயன்படுத்தாத அளவுக்கு வித்தியாசம் பெரிதாக இல்லை.

நீங்கள் இயக்க முறைகளை ஒப்பிட்டுப் பார்த்தால் ஒரு வலுவான வேறுபாடு உள்ளது என்பதை நினைவில் கொள்ளவும்: நீங்கள் ஒரே அமர்வில் அல்லது வெவ்வேறு அமர்வுகளில் வேலை செய்கிறீர்கள். இது புரிந்துகொள்ளத்தக்கது: ஒவ்வொரு இணைப்பை உருவாக்குவதற்கு ஆதாரங்கள் செலவிடப்படுகின்றன.

நாங்கள் Zabbix ஐ நம்பிக்கை பயன்முறையில் இணைத்தபோது ஒரு வழக்கு இருந்தது, அதாவது md5 சரிபார்க்கப்படவில்லை, அங்கீகாரம் தேவையில்லை. பின்னர் வாடிக்கையாளர் md5 அங்கீகார பயன்முறையை இயக்கும்படி கேட்டார். இது CPU இல் அதிக சுமையை ஏற்படுத்தியது, மேலும் செயல்திறன் குறைந்தது. மேம்படுத்துவதற்கான வழிகளைத் தேடத் தொடங்கினோம். நெட்வொர்க் கட்டுப்பாடுகளைச் செயல்படுத்துவது, DBMSக்கு தனி VLANகளை உருவாக்குவது, எங்கிருந்து யார் இணைக்கிறார்கள் என்பதைத் தெளிவுபடுத்த அமைப்புகளைச் சேர்ப்பது மற்றும் அங்கீகாரத்தை அகற்றுவது ஆகியவை சிக்கலுக்கான சாத்தியமான தீர்வுகளில் ஒன்றாகும். பொதுவாக வெவ்வேறு முறைகளின் அங்கீகாரத்தைப் பயன்படுத்துவது செயல்திறனைப் பாதிக்கிறது மற்றும் DBMSக்கான சேவையகங்களின் (வன்பொருள்) கம்ப்யூட்டிங் சக்தியை வடிவமைக்கும்போது இந்தக் காரணிகளைக் கணக்கில் எடுத்துக்கொள்ள வேண்டும்.

முடிவு: பல தீர்வுகளில், அங்கீகாரத்தில் சிறிய நுணுக்கங்கள் கூட திட்டத்தை பெரிதும் பாதிக்கலாம் மற்றும் உற்பத்தியில் செயல்படுத்தப்படும் போது மட்டுமே இது தெளிவாகிறது.

அதிரடி தணிக்கை

தணிக்கை DBMS மட்டுமல்ல. தணிக்கை என்பது வெவ்வேறு பிரிவுகளில் என்ன நடக்கிறது என்பது பற்றிய தகவல்களைப் பெறுவதாகும். இது தரவுத்தள ஃபயர்வால் அல்லது DBMS கட்டமைக்கப்பட்ட இயங்குதளமாக இருக்கலாம்.

வணிக நிறுவன நிலை DBMSகளில், தணிக்கையில் எல்லாம் நன்றாக இருக்கிறது, ஆனால் திறந்த மூலத்தில் - எப்போதும் இல்லை. PostgreSQL என்ன இருக்கிறது என்பது இங்கே:

  • இயல்புநிலை பதிவு - உள்ளமைக்கப்பட்ட பதிவு;
  • நீட்டிப்புகள்: pgaudit - இயல்புநிலை பதிவு போதுமானதாக இல்லை என்றால், சில சிக்கல்களைத் தீர்க்கும் தனி அமைப்புகளைப் பயன்படுத்தலாம்.

வீடியோவில் உள்ள அறிக்கைக்கு கூடுதலாக:

"லாக்_ஸ்டேட்மென்ட் = அனைத்தும் கொண்ட நிலையான பதிவு வசதி மூலம் அடிப்படை அறிக்கை பதிவு செய்ய முடியும்.

இது கண்காணிப்பு மற்றும் பிற பயன்பாடுகளுக்கு ஏற்கத்தக்கது, ஆனால் தணிக்கைக்கு பொதுவாக தேவைப்படும் விவரத்தின் அளவை வழங்காது.

தரவுத்தளத்தில் செய்யப்படும் அனைத்து செயல்பாடுகளின் பட்டியலை வைத்திருப்பது போதாது.

தணிக்கையாளருக்கு ஆர்வமுள்ள குறிப்பிட்ட அறிக்கைகளைக் கண்டறியவும் முடியும்.

நிலையான பதிவு செய்தல் பயனர் கோரியதைக் காட்டுகிறது, அதே சமயம் pgAudit தரவுத்தளம் வினவலைச் செயல்படுத்தும்போது என்ன நடந்தது என்ற விவரங்களில் கவனம் செலுத்துகிறது.

எடுத்துக்காட்டாக, ஆவணப்படுத்தப்பட்ட பராமரிப்பு சாளரத்தில் ஒரு குறிப்பிட்ட அட்டவணை உருவாக்கப்பட்டது என்பதை தணிக்கையாளர் சரிபார்க்க விரும்பலாம்.

அடிப்படை தணிக்கை மற்றும் grep உடன் இது ஒரு எளிய பணியாகத் தோன்றலாம், ஆனால் இது போன்ற (வேண்டுமென்றே குழப்பமான) உதாரணம் உங்களுக்கு வழங்கப்பட்டால் என்ன செய்வது:

செய்ய $$
BEGIN
'டேபிள் இறக்குமதியை உருவாக்கு' || 'ant_table(id int)';
END$$;

நிலையான பதிவு உங்களுக்கு இதை வழங்கும்:

பதிவு: அறிக்கை: செய்ய $$
BEGIN
'டேபிள் இறக்குமதியை உருவாக்கு' || 'ant_table(id int)';
END$$;

அட்டவணைகள் மாறும் வகையில் உருவாக்கப்பட்ட சந்தர்ப்பங்களில் ஆர்வமுள்ள அட்டவணையைக் கண்டுபிடிப்பதற்கு சில குறியீடு அறிவு தேவைப்படலாம் என்று தோன்றுகிறது.

இது சிறந்ததல்ல, ஏனெனில் அட்டவணையின் பெயரால் தேடுவது விரும்பத்தக்கது.

இங்குதான் pgAudit பயனுள்ளதாக இருக்கும்.

அதே உள்ளீட்டிற்கு, இது பதிவில் இந்த வெளியீட்டை உருவாக்கும்:

தணிக்கை: அமர்வு, 33,1, செயல்பாடு, செய்,,,"செய் $$
BEGIN
'டேபிள் இறக்குமதியை உருவாக்கு' || 'ant_table(id int)';
END$$;"
தணிக்கை: அமர்வு, 33,2, DDL, அட்டவணையை உருவாக்கு, அட்டவணை, பொது.முக்கிய_அட்டவணை, முக்கியமான_அட்டவணையை உருவாக்கு (ஐடி INT)

DO பிளாக் மட்டும் பதிவு செய்யப்படவில்லை, ஆனால் CREATE TABLE இன் முழு உரையும் அறிக்கை வகை, பொருள் வகை மற்றும் முழுப் பெயருடன் தேடலை எளிதாக்குகிறது.

SELECT மற்றும் DML அறிக்கைகளை பதிவு செய்யும் போது, ​​pgAudit ஆனது அறிக்கையில் குறிப்பிடப்பட்டுள்ள ஒவ்வொரு உறவிற்கும் தனித்தனி உள்ளீட்டை பதிவு செய்ய உள்ளமைக்கப்படும்.

குறிப்பிட்ட அட்டவணையைத் தொடும் அனைத்து அறிக்கைகளையும் கண்டறிய பாகுபடுத்த வேண்டிய அவசியமில்லை(*) ”.

இது DBMS இன் செயல்திறனை எவ்வாறு பாதிக்கும்?

முழு தணிக்கை இயக்கப்பட்ட சோதனைகளை இயக்கலாம் மற்றும் PostgreSQL செயல்திறனுக்கு என்ன நடக்கிறது என்று பார்க்கலாம். அனைத்து அளவுருக்களுக்கும் அதிகபட்ச தரவுத்தள பதிவுகளை இயக்குவோம்.

உள்ளமைவு கோப்பில் நாங்கள் எதையும் மாற்றவில்லை, மிக முக்கியமான விஷயம் அதிகபட்ச தகவலைப் பெற debug5 பயன்முறையை இயக்குவது.

postgresql.conf

log_destination = 'stderr'
logging_collector = ஆன்
log_truncate_on_rotation = ஆன்
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = பிழைத்திருத்தம்5
log_min_error_statement = பிழைத்திருத்தம்5
log_min_duration_statement = 0
debug_print_parse = ஆன்
debug_print_rewritten = ஆன்
debug_print_plan = ஆன்
debug_pretty_print = ஆன்
log_checkpoints = on
log_connections = ஆன்
log_disconnections = ஆன்
பதிவு_காலம் = ஆன்
log_hostname = on
log_lock_wait = ஆன்
log_replication_commands = ஆன்
log_temp_files = 0
log_timezone = 'ஐரோப்பா/மாஸ்கோ'

1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD அளவுருக்கள் கொண்ட PostgreSQL DBMS இல், கட்டளைகளைப் பயன்படுத்தி மூன்று சுமை சோதனைகளை நடத்துகிறோம்:

$ 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

சோதனை முடிவுகள்:

பதிவு இல்லை
பதிவுடன்

மொத்த தரவுத்தள நிரப்புதல் நேரம்
43,74 நொடி
53,23 நொடி

ரேம்
24%
40%

சிபியு
72%
91%

சோதனை 1 (50 இணைப்புகள்)

10 நிமிடங்களில் பரிவர்த்தனைகளின் எண்ணிக்கை
74169
32445

பரிவர்த்தனைகள்/வினாடி
123
54

சராசரி தாமதம்
405 எம்.எஸ்
925 எம்.எஸ்

சோதனை 2 (150 உடன் 100 இணைப்புகள் சாத்தியம்)

10 நிமிடங்களில் பரிவர்த்தனைகளின் எண்ணிக்கை
81727
31429

பரிவர்த்தனைகள்/வினாடி
136
52

சராசரி தாமதம்
550 எம்.எஸ்
1432 எம்.எஸ்

அளவுகள் பற்றி

DB அளவு
2251 எம்பி
2262 எம்பி

தரவுத்தள பதிவு அளவு
எக்ஸ்எம்எல் MB
எக்ஸ்எம்எல் MB

கீழே வரி: முழு தணிக்கை மிகவும் நன்றாக இல்லை. தணிக்கையின் தரவு தரவுத்தளத்தில் உள்ள தரவைப் போலவே பெரியதாக இருக்கும் அல்லது இன்னும் அதிகமாக இருக்கும். DBMS உடன் பணிபுரியும் போது உருவாக்கப்படும் பதிவுகளின் அளவு உற்பத்தியில் பொதுவான பிரச்சனையாகும்.

மற்ற அளவுருக்களைப் பார்ப்போம்:

  • வேகம் அதிகம் மாறாது: பதிவு செய்யாமல் - 43,74 வினாடிகள், உள்நுழைவுடன் - 53,23 வினாடிகள்.
  • ரேம் மற்றும் CPU செயல்திறன் பாதிக்கப்படும், ஏனெனில் நீங்கள் தணிக்கை கோப்பை உருவாக்க வேண்டும். உற்பத்தித்திறனிலும் இது கவனிக்கத்தக்கது.

இணைப்புகளின் எண்ணிக்கை அதிகரிக்கும் போது, ​​இயற்கையாகவே, செயல்திறன் சற்று மோசமடையும்.

தணிக்கை கொண்ட நிறுவனங்களில் இது மிகவும் கடினம்:

  • நிறைய தரவு உள்ளது;
  • SIEM இல் உள்ள syslog மூலம் மட்டுமல்ல, கோப்புகளிலும் தணிக்கை தேவைப்படுகிறது: syslogக்கு ஏதேனும் நேர்ந்தால், தரவு சேமிக்கப்பட்ட தரவுத்தளத்திற்கு அருகில் ஒரு கோப்பு இருக்க வேண்டும்;
  • I/O வட்டுகளை வீணாக்காமல் இருக்க, தணிக்கைக்கு ஒரு தனி அலமாரி தேவை, ஏனெனில் இது அதிக இடத்தை எடுத்துக்கொள்கிறது;
  • தகவல் பாதுகாப்பு ஊழியர்களுக்கு எல்லா இடங்களிலும் GOST தரநிலைகள் தேவை, அவர்களுக்கு மாநில அடையாளம் தேவை.

தரவுக்கான அணுகலைக் கட்டுப்படுத்துகிறது

வணிக DBMSகள் மற்றும் ஓப்பன் சோர்ஸில் தரவைப் பாதுகாப்பதற்கும் அதை அணுகுவதற்கும் பயன்படுத்தப்படும் தொழில்நுட்பங்களைப் பார்ப்போம்.

நீங்கள் பொதுவாக எதைப் பயன்படுத்தலாம்:

  1. செயல்முறைகள் மற்றும் செயல்பாடுகளின் குறியாக்கம் மற்றும் தெளிவின்மை (Wrapping) - அதாவது, படிக்கக்கூடிய குறியீட்டை படிக்க முடியாதபடி செய்யும் தனி கருவிகள் மற்றும் பயன்பாடுகள். உண்மை, பின்னர் அதை மாற்றவோ அல்லது மறுசீரமைக்கவோ முடியாது. இந்த அணுகுமுறை சில சமயங்களில் குறைந்தபட்சம் DBMS பக்கத்திலாவது தேவைப்படுகிறது - உரிமக் கட்டுப்பாடுகள் அல்லது அங்கீகார தர்க்கத்தின் தர்க்கம் செயல்முறை மற்றும் செயல்பாட்டு மட்டத்தில் துல்லியமாக குறியாக்கம் செய்யப்படுகிறது.
  2. வரிசைகள் மூலம் தரவின் தெரிவுநிலையை வரம்பிடுவது (RLS) என்பது வெவ்வேறு பயனர்கள் ஒரு அட்டவணையைப் பார்க்கும்போது, ​​ஆனால் அதில் வரிசைகளின் வேறுபட்ட கலவை, அதாவது வரிசை மட்டத்தில் உள்ள ஒருவருக்குக் காட்ட முடியாது.
  3. காட்டப்படும் தரவைத் திருத்துவது (மாஸ்கிங்) என்பது அட்டவணையின் ஒரு நெடுவரிசையில் உள்ள பயனர்கள் தரவு அல்லது நட்சத்திரக் குறிகளை மட்டுமே பார்ப்பது, அதாவது சில பயனர்களுக்குத் தகவல் மூடப்படும். எந்த பயனருக்கு அவர்களின் அணுகல் நிலையின் அடிப்படையில் என்ன காட்டப்பட வேண்டும் என்பதை தொழில்நுட்பம் தீர்மானிக்கிறது.
  4. பாதுகாப்பு டிபிஏ/பயன்பாடு டிபிஏ/டிபிஏ அணுகல் கட்டுப்பாடு என்பது, டிபிஎம்எஸ்ஸிற்கான அணுகலைக் கட்டுப்படுத்துவதாகும், அதாவது, தகவல் பாதுகாப்பு ஊழியர்களை தரவுத்தள நிர்வாகிகள் மற்றும் பயன்பாட்டு நிர்வாகிகளிடமிருந்து பிரிக்கலாம். திறந்த மூலத்தில் இதுபோன்ற சில தொழில்நுட்பங்கள் உள்ளன, ஆனால் வணிக DBMS களில் அவை ஏராளமாக உள்ளன. சேவையகங்களை அணுகக்கூடிய பல பயனர்கள் இருக்கும்போது அவை தேவைப்படுகின்றன.
  5. கோப்பு முறைமை மட்டத்தில் கோப்புகளுக்கான அணுகலைக் கட்டுப்படுத்துகிறது. நீங்கள் கோப்பகங்களுக்கு உரிமைகள் மற்றும் அணுகல் சலுகைகளை வழங்கலாம், இதனால் ஒவ்வொரு நிர்வாகியும் தேவையான தரவுகளுக்கு மட்டுமே அணுகலைப் பெறலாம்.
  6. கட்டாய அணுகல் மற்றும் நினைவக நீக்கம் - இந்த தொழில்நுட்பங்கள் அரிதாகவே பயன்படுத்தப்படுகின்றன.
  7. டிபிஎம்எஸ்ஸிலிருந்து நேரடியாக எண்ட்-டு-எண்ட் என்க்ரிப்ஷன் என்பது சர்வர் பக்கத்தில் உள்ள முக்கிய நிர்வாகத்துடன் கிளையன்ட் பக்க குறியாக்கமாகும்.
  8. தரவு குறியாக்கம். எடுத்துக்காட்டாக, தரவுத்தளத்தின் ஒரு நெடுவரிசையை குறியாக்கம் செய்யும் பொறிமுறையைப் பயன்படுத்தும் போது நிரல் குறியாக்கம் ஆகும்.

இது DBMS இன் செயல்திறனை எவ்வாறு பாதிக்கிறது?

PostgreSQL இல் நெடுவரிசை குறியாக்கத்தின் உதாரணத்தைப் பார்ப்போம். ஒரு pgcrypto தொகுதி உள்ளது, இது தேர்ந்தெடுக்கப்பட்ட புலங்களை மறைகுறியாக்கப்பட்ட வடிவத்தில் சேமிக்க உங்களை அனுமதிக்கிறது. சில தரவு மட்டுமே மதிப்புமிக்கதாக இருக்கும்போது இது பயனுள்ளதாக இருக்கும். மறைகுறியாக்கப்பட்ட புலங்களைப் படிக்க, கிளையன்ட் ஒரு மறைகுறியாக்க விசையை அனுப்புகிறது, சேவையகம் தரவை மறைகுறியாக்கி கிளையண்டிற்கு திருப்பித் தருகிறது. சாவி இல்லாமல், உங்கள் தரவை யாராலும் எதுவும் செய்ய முடியாது.

pgcrypto மூலம் சோதிப்போம். மறைகுறியாக்கப்பட்ட தரவு மற்றும் வழக்கமான தரவுகளுடன் அட்டவணையை உருவாக்குவோம். அட்டவணைகளை உருவாக்குவதற்கான கட்டளைகள் கீழே உள்ளன, முதல் வரியில் ஒரு பயனுள்ள கட்டளை உள்ளது - 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'));

அடுத்து, ஒவ்வொரு அட்டவணையிலிருந்தும் ஒரு தரவு மாதிரியை உருவாக்கி, செயல்படுத்தும் நேரத்தைப் பார்க்கலாம்.

குறியாக்க செயல்பாடு இல்லாமல் ஒரு அட்டவணையில் இருந்து தேர்ந்தெடுப்பது:

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

ஸ்டாப்வாட்ச் இயக்கத்தில் உள்ளது.

  ஐடி | உரை1 | உரை2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 வரிகள்)

நேரம்: 1,386 எம்.எஸ்

குறியாக்க செயல்பாடு கொண்ட அட்டவணையில் இருந்து தேர்வு:

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

ஸ்டாப்வாட்ச் இயக்கத்தில் உள்ளது.

  ஐடி | மறைகுறியாக்கம் | மறைகுறியாக்கம்
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 வரிகள்)

நேரம்: 50,203 எம்.எஸ்

சோதனை முடிவுகள்:

 
குறியாக்கம் இல்லாமல்
Pgcrypto (டிக்ரிப்ட்)

மாதிரி 1000 வரிசைகள்
1,386 எம்.எஸ்
50,203 எம்.எஸ்

சிபியு
15%
35%

ரேம்
 
+ 5%

குறியாக்கம் செயல்திறனில் பெரிய தாக்கத்தை ஏற்படுத்துகிறது. மறைகுறியாக்கப்பட்ட தரவின் மறைகுறியாக்க செயல்பாடுகளுக்கு (மற்றும் மறைகுறியாக்கம் பொதுவாக உங்கள் தர்க்கத்தில் மூடப்பட்டிருக்கும்) குறிப்பிடத்தக்க ஆதாரங்கள் தேவைப்படுவதால், நேரம் அதிகரித்திருப்பதைக் காணலாம். அதாவது, சில தரவுகளைக் கொண்ட அனைத்து நெடுவரிசைகளையும் குறியாக்கம் செய்யும் யோசனை செயல்திறன் குறைவினால் நிறைந்துள்ளது.

இருப்பினும், குறியாக்கம் என்பது எல்லா பிரச்சனைகளையும் தீர்க்கும் வெள்ளி புல்லட் அல்ல. டிக்ரிப்ட் செய்யப்பட்ட தரவு மற்றும் தரவை மறைகுறியாக்கம் செய்து கடத்தும் செயல்பாட்டின் போது மறைகுறியாக்க விசை ஆகியவை சேவையகத்தில் அமைந்துள்ளன. எனவே, கணினி நிர்வாகி போன்ற தரவுத்தள சேவையகத்திற்கு முழு அணுகலைக் கொண்ட ஒருவரால் விசைகளை இடைமறிக்க முடியும்.

அனைத்து பயனர்களுக்கும் முழு நெடுவரிசைக்கும் ஒரு விசை இருக்கும்போது (அனைவருக்கும் இல்லாவிட்டாலும், வரையறுக்கப்பட்ட தொகுப்பின் வாடிக்கையாளர்களுக்கு), இது எப்போதும் நல்லதாகவும் சரியானதாகவும் இருக்காது. அதனால்தான் அவர்கள் என்ட்-டு-எண்ட் குறியாக்கத்தைச் செய்யத் தொடங்கினர், டிபிஎம்எஸ்ஸில் கிளையன்ட் மற்றும் சர்வர் பக்கத்தில் தரவை குறியாக்கம் செய்வதற்கான விருப்பங்களை அவர்கள் பரிசீலிக்கத் தொடங்கினர், அதே கீ-வால்ட் சேமிப்பகங்கள் தோன்றின - டிபிஎம்எஸ்ஸில் முக்கிய நிர்வாகத்தை வழங்கும் தனி தயாரிப்புகள். பக்கம்.

பாதுகாப்பு மற்றும் DBMS: பாதுகாப்புக் கருவிகளைத் தேர்ந்தெடுக்கும்போது நீங்கள் நினைவில் கொள்ள வேண்டியவை
மோங்கோடிபியில் இத்தகைய குறியாக்கத்திற்கான எடுத்துக்காட்டு

வணிக மற்றும் திறந்த மூல DBMS இல் பாதுகாப்பு அம்சங்கள்

செயல்பாடுகளை
வகை
கடவுச்சொல் கொள்கை
தணிக்கை
செயல்முறைகள் மற்றும் செயல்பாடுகளின் மூலக் குறியீட்டைப் பாதுகாத்தல்
RLS
குறியாக்க

Oracle
வணிக
+
+
+
+
+

MsSql
வணிக
+
+
+
+
+

ஜடோபா
வணிக
+
+
+
+
நீட்சிகள்

போஸ்ட்கெரே
இலவச
நீட்சிகள்
நீட்சிகள்
-
+
நீட்சிகள்

மோங்கோடிபி
இலவச
-
+
-
-
MongoDB நிறுவனத்தில் மட்டுமே கிடைக்கும்

அட்டவணை முழுமையடையவில்லை, ஆனால் நிலைமை இதுதான்: வணிக தயாரிப்புகளில், பாதுகாப்பு சிக்கல்கள் நீண்ட காலமாக தீர்க்கப்பட்டுள்ளன, திறந்த மூலத்தில், ஒரு விதியாக, பாதுகாப்பிற்காக சில வகையான துணை நிரல்கள் பயன்படுத்தப்படுகின்றன, பல செயல்பாடுகள் இல்லை. , சில நேரங்களில் நீங்கள் ஏதாவது சேர்க்க வேண்டும். எடுத்துக்காட்டாக, கடவுச்சொல் கொள்கைகள் - PostgreSQL பல்வேறு நீட்டிப்புகளைக் கொண்டுள்ளது (1, 2, 3, 4, 5), இது கடவுச்சொல் கொள்கைகளை செயல்படுத்துகிறது, ஆனால், என் கருத்துப்படி, அவை எதுவும் உள்நாட்டு பெருநிறுவனப் பிரிவின் அனைத்து தேவைகளையும் உள்ளடக்குவதில்லை.

எங்கும் உங்களுக்குத் தேவையானவை இல்லை என்றால் என்ன செய்வது? எடுத்துக்காட்டாக, வாடிக்கையாளருக்குத் தேவையான செயல்பாடுகள் இல்லாத குறிப்பிட்ட DBMSஐப் பயன்படுத்த விரும்புகிறீர்கள்.

வெவ்வேறு DBMSகளுடன் வேலை செய்யும் மூன்றாம் தரப்பு தீர்வுகளை நீங்கள் பயன்படுத்தலாம், எடுத்துக்காட்டாக, Crypto DB அல்லது Garda DB. உள்நாட்டுப் பிரிவில் இருந்து தீர்வுகளைப் பற்றி நாங்கள் பேசுகிறோம் என்றால், அவர்கள் திறந்த மூலத்தை விட GOST களைப் பற்றி நன்றாக அறிந்திருக்கிறார்கள்.

இரண்டாவது விருப்பம், உங்களுக்குத் தேவையானதை நீங்களே எழுதுவது, செயல்முறை மட்டத்தில் பயன்பாட்டில் தரவு அணுகல் மற்றும் குறியாக்கத்தை செயல்படுத்துவது. உண்மை, இது GOST உடன் மிகவும் கடினமாக இருக்கும். ஆனால் பொதுவாக, நீங்கள் தேவைக்கேற்ப தரவை மறைக்கலாம், அதை ஒரு DBMS இல் வைத்து, பின்னர் அதை மீட்டெடுக்கலாம் மற்றும் தேவைக்கேற்ப டிக்ரிப்ட் செய்யலாம், பயன்பாட்டு மட்டத்திலேயே. அதே நேரத்தில், பயன்பாட்டில் இந்த வழிமுறைகளை எவ்வாறு பாதுகாப்பீர்கள் என்பதைப் பற்றி உடனடியாக சிந்தியுங்கள். எங்கள் கருத்துப்படி, இது DBMS மட்டத்தில் செய்யப்பட வேண்டும், ஏனெனில் இது வேகமாக வேலை செய்யும்.

இந்த அறிக்கை முதலில் சமர்ப்பிக்கப்பட்டது @டேட்டாபேஸ் சந்திப்பு Mail.ru கிளவுட் தீர்வுகள் மூலம். பார் видео மற்ற நிகழ்ச்சிகள் மற்றும் டெலிகிராமில் நிகழ்வு அறிவிப்புகளுக்கு குழுசேரவும் Mail.ru குழுவில் Kubernetes சுற்றி.

தலைப்பில் வேறு என்ன படிக்க வேண்டும்:

  1. Ceph ஐ விட அதிகம்: MCS கிளவுட் தொகுதி சேமிப்பகம்.
  2. ஒரு திட்டத்திற்கான தரவுத்தளத்தை எவ்வாறு தேர்வு செய்வது, எனவே நீங்கள் மீண்டும் தேர்வு செய்ய வேண்டியதில்லை.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்