ਮੇਰਾ ਨਾਮ ਡੇਨਿਸ ਰੋਜ਼ਕੋਵ ਹੈ, ਮੈਂ ਉਤਪਾਦ ਟੀਮ ਵਿੱਚ ਗਜ਼ੀਨਫਾਰਮਸਰਵਿਸ ਕੰਪਨੀ ਵਿੱਚ ਸਾਫਟਵੇਅਰ ਵਿਕਾਸ ਦਾ ਮੁਖੀ ਹਾਂ ਜਟੋਬਾ. ਕਾਨੂੰਨ ਅਤੇ ਕਾਰਪੋਰੇਟ ਨਿਯਮ ਡਾਟਾ ਸਟੋਰੇਜ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਕੁਝ ਲੋੜਾਂ ਲਾਉਂਦੇ ਹਨ। ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਚਾਹੁੰਦਾ ਕਿ ਤੀਜੀ ਧਿਰ ਗੁਪਤ ਜਾਣਕਾਰੀ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰੇ, ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਪ੍ਰੋਜੈਕਟ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਮੁੱਦੇ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਪਛਾਣ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ, ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ, ਸਿਸਟਮ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਸੁਰੱਖਿਆ ਇਵੈਂਟਾਂ ਨੂੰ ਲੌਗ ਕਰਨਾ। ਇਸ ਲਈ, ਮੈਂ DBMS ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਕੁਝ ਦਿਲਚਸਪ ਨੁਕਤਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ.

'ਤੇ ਦਿੱਤੇ ਭਾਸ਼ਣ ਦੇ ਆਧਾਰ 'ਤੇ ਲੇਖ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ @DatabasesMeetup, ਆਯੋਜਿਤ Mail.ru ਕਲਾਉਡ ਹੱਲ. ਜੇ ਤੁਸੀਂ ਪੜ੍ਹਨਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ:

ਲੇਖ ਦੇ ਤਿੰਨ ਭਾਗ ਹੋਣਗੇ:

• ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਹੈ।
• ਕਿਰਿਆਵਾਂ ਦਾ ਆਡਿਟ ਕੀ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਸਾਈਡ 'ਤੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜਨਾ ਕਿਵੇਂ ਰਿਕਾਰਡ ਕਰਨਾ ਹੈ।
• ਡੇਟਾਬੇਸ ਵਿੱਚ ਹੀ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਇਸਦੇ ਲਈ ਕਿਹੜੀਆਂ ਤਕਨੀਕਾਂ ਉਪਲਬਧ ਹਨ।

DBMS ਸੁਰੱਖਿਆ ਦੇ ਤਿੰਨ ਭਾਗ: ਕਨੈਕਸ਼ਨ ਸੁਰੱਖਿਆ, ਗਤੀਵਿਧੀ ਆਡਿਟਿੰਗ ਅਤੇ ਡੇਟਾ ਸੁਰੱਖਿਆ

ਤੁਹਾਡੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ

ਤੁਸੀਂ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਰਾਹੀਂ ਸਿੱਧੇ ਜਾਂ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹੋ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਵਪਾਰਕ ਉਪਭੋਗਤਾ, ਭਾਵ, ਉਹ ਵਿਅਕਤੀ ਜੋ DBMS ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਨਾਲ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ.

ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਸੁਰੱਖਿਆ ਬਾਰੇ ਗੱਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਸੁਰੱਖਿਆ ਉਪਾਅ ਕਿਵੇਂ ਬਣਾਏ ਜਾਣਗੇ:

• ਕੀ ਇੱਕ ਵਪਾਰਕ ਉਪਭੋਗਤਾ ਇੱਕ DBMS ਉਪਭੋਗਤਾ ਦੇ ਬਰਾਬਰ ਹੈ?
• ਕੀ DBMS ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਕੇਵਲ ਇੱਕ API ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ, ਜਾਂ ਕੀ ਟੇਬਲਾਂ ਨੂੰ ਸਿੱਧੇ ਐਕਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ;
• ਕੀ DBMS ਇੱਕ ਵੱਖਰੇ ਸੁਰੱਖਿਅਤ ਹਿੱਸੇ ਨੂੰ ਅਲਾਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਕੌਣ ਇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ;
• ਕੀ ਪੂਲਿੰਗ/ਪ੍ਰੌਕਸੀ ਅਤੇ ਇੰਟਰਮੀਡੀਏਟ ਲੇਅਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਕੌਣ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਹੈ।

ਹੁਣ ਆਓ ਦੇਖੀਏ ਕਿ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਕਿਹੜੇ ਸਾਧਨ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ:

1. ਡਾਟਾਬੇਸ ਫਾਇਰਵਾਲ ਕਲਾਸ ਹੱਲ ਵਰਤੋ. ਸੁਰੱਖਿਆ ਦੀ ਇੱਕ ਵਾਧੂ ਪਰਤ, ਘੱਟੋ-ਘੱਟ, DBMS ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਦੀ ਪਾਰਦਰਸ਼ਤਾ ਨੂੰ ਵਧਾਏਗੀ, ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ, ਤੁਸੀਂ ਵਾਧੂ ਡਾਟਾ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੋਗੇ।
2. ਪਾਸਵਰਡ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡਾ ਆਰਕੀਟੈਕਚਰ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਪਾਸਵਰਡ ਜੋ DBMS ਨਾਲ ਜੁੜਦਾ ਹੈ ਸੁਰੱਖਿਆ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ DBMS ਟੂਲ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਇਹ ਨਿਯੰਤਰਣ ਕਰਨ ਦਿੰਦੇ ਹਨ ਕਿ ਉਪਭੋਗਤਾ ਅਤੇ ਪਾਸਵਰਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

   ਤੁਸੀਂ ਉਪਭੋਗਤਾ ਰੇਟਿੰਗ ਫੰਕਸ਼ਨਾਂ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ, ਤੁਸੀਂ MS SQL Vulnerability Assessmen ਬਾਰੇ ਵੀ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਇੱਥੇ. 

3. ਜ਼ਰੂਰੀ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਸੈਸ਼ਨ ਦੇ ਸੰਦਰਭ ਨੂੰ ਭਰਪੂਰ ਬਣਾਓ। ਜੇਕਰ ਸੈਸ਼ਨ ਅਪਾਰਦਰਸ਼ੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਹੋ ਕਿ DBMS ਵਿੱਚ ਇਸਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ ਕੌਣ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤੁਸੀਂ, ਕੀਤੇ ਜਾ ਰਹੇ ਓਪਰੇਸ਼ਨ ਦੇ ਢਾਂਚੇ ਦੇ ਅੰਦਰ, ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੌਣ ਕੀ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਉਂ। ਇਹ ਜਾਣਕਾਰੀ ਆਡਿਟ ਵਿੱਚ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ।
4. SSL ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ DBMS ਅਤੇ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਨੈੱਟਵਰਕ ਵੱਖਰਾ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਵੱਖਰੇ VLAN ਵਿੱਚ ਨਹੀਂ ਹੈ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਅਤੇ DBMS ਦੇ ਵਿਚਕਾਰ ਚੈਨਲ ਦੀ ਰੱਖਿਆ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਸੁਰੱਖਿਆ ਟੂਲ ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਵੀ ਉਪਲਬਧ ਹਨ।

ਇਹ DBMS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰੇਗਾ?

ਆਉ ਇਹ ਦੇਖਣ ਲਈ PostgreSQL ਦੀ ਉਦਾਹਰਨ ਦੇਖੀਏ ਕਿ SSL CPU ਲੋਡ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਸਮਾਂ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ TPS ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਸਮਰੱਥ ਕਰਦੇ ਹੋ।

Pgbench ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ PostgreSQL ਨੂੰ ਲੋਡ ਕਰਨਾ ਕਾਰਗੁਜ਼ਾਰੀ ਟੈਸਟਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰੋਗਰਾਮ ਹੈ। ਇਹ ਵਾਰ-ਵਾਰ ਕਮਾਂਡਾਂ ਦੇ ਇੱਕ ਸਿੰਗਲ ਕ੍ਰਮ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਸੰਭਵ ਤੌਰ 'ਤੇ ਸਮਾਂਤਰ ਡੇਟਾਬੇਸ ਸੈਸ਼ਨਾਂ ਵਿੱਚ, ਅਤੇ ਫਿਰ ਔਸਤ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦਰ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ।

ਟੈਸਟ 1 ਬਿਨਾਂ SSL ਅਤੇ SSL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ - ਹਰੇਕ ਲੈਣ-ਦੇਣ ਲਈ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ:

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"

ਟੈਸਟ 2 ਬਿਨਾਂ SSL ਅਤੇ SSL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ - ਸਾਰੇ ਲੈਣ-ਦੇਣ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਵਿੱਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

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

CPU
24%
28%

ਸਾਰੇ ਲੈਣ-ਦੇਣ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਵਿੱਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ

ਲੇਟੈਂਸੀ ਔਸਤ
6.722 ਮੀ
6.342 ਮੀ

ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਸਮੇਤ tps
1587.657278
1576.792883

ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਨੂੰ ਛੱਡ ਕੇ tps
1588.380574
1577.694766

CPU
17%
21%

ਹਲਕੇ ਲੋਡ 'ਤੇ, SSL ਦਾ ਪ੍ਰਭਾਵ ਮਾਪ ਦੀ ਗਲਤੀ ਨਾਲ ਤੁਲਨਾਯੋਗ ਹੈ। ਜੇਕਰ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ, ਤਾਂ ਸਥਿਤੀ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਪ੍ਰਤੀ ਲੈਣ-ਦੇਣ ਇੱਕ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਦੇ ਹਾਂ (ਇਹ ਬਹੁਤ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਕਨੈਕਸ਼ਨ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ), ਤੁਹਾਡੇ ਕੋਲ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਕੁਨੈਕਸ਼ਨ/ਡਿਸਕਨੈਕਸ਼ਨ ਹਨ, ਪ੍ਰਭਾਵ ਥੋੜਾ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ। ਭਾਵ, ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਮੀ ਦੇ ਜੋਖਮ ਹੋ ਸਕਦੇ ਹਨ, ਹਾਲਾਂਕਿ, ਅੰਤਰ ਇੰਨਾ ਵੱਡਾ ਨਹੀਂ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਦੀ ਵਰਤੋਂ ਨਾ ਕੀਤੀ ਜਾਵੇ।

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਉ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਓਪਰੇਟਿੰਗ ਮੋਡਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ ਤਾਂ ਇੱਕ ਮਜ਼ਬੂਤ ​​ਫਰਕ ਹੈ: ਤੁਸੀਂ ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ ਜਾਂ ਵੱਖ-ਵੱਖ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ। ਇਹ ਸਮਝਣ ਯੋਗ ਹੈ: ਸਰੋਤ ਹਰੇਕ ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਣ 'ਤੇ ਖਰਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਸਾਡੇ ਕੋਲ ਇੱਕ ਕੇਸ ਸੀ ਜਦੋਂ ਅਸੀਂ ਜ਼ੈਬਿਕਸ ਨੂੰ ਟਰੱਸਟ ਮੋਡ ਵਿੱਚ ਕਨੈਕਟ ਕੀਤਾ ਸੀ, ਯਾਨੀ md5 ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ, ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਸੀ। ਫਿਰ ਗਾਹਕ ਨੇ md5 ਪ੍ਰਮਾਣੀਕਰਨ ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ ਕਿਹਾ। ਇਸ ਨਾਲ CPU 'ਤੇ ਭਾਰੀ ਬੋਝ ਪੈ ਗਿਆ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਘਟ ਗਿਆ। ਅਸੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ ਲੱਭਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ। ਸਮੱਸਿਆ ਦੇ ਸੰਭਾਵੀ ਹੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਨੈੱਟਵਰਕ ਪਾਬੰਦੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ, DBMS ਲਈ ਵੱਖਰੇ VLAN ਬਣਾਉਣਾ, ਇਹ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਸੈਟਿੰਗਾਂ ਜੋੜਨਾ ਕਿ ਕੌਣ ਕਿੱਥੋਂ ਕਨੈਕਟ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਹਟਾਓ। ਤੁਸੀਂ ਪ੍ਰਮਾਣੀਕਰਨ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਵੇਲੇ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਸੈਟਿੰਗਾਂ ਨੂੰ ਵੀ ਅਨੁਕੂਲਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਅਤੇ DBMS ਲਈ ਸਰਵਰਾਂ (ਹਾਰਡਵੇਅਰ) ਦੀ ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਸਮੇਂ ਇਹਨਾਂ ਕਾਰਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਿੱਟਾ: ਬਹੁਤ ਸਾਰੇ ਹੱਲਾਂ ਵਿੱਚ, ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ ਵੀ ਛੋਟੀਆਂ ਬਾਰੀਕੀਆਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਉਦੋਂ ਮਾੜਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਉਦੋਂ ਹੀ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਤਪਾਦਨ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਐਕਸ਼ਨ ਆਡਿਟ

ਆਡਿਟ ਨਾ ਸਿਰਫ਼ DBMS ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਆਡਿਟ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਇਸ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਬਾਰੇ ਹੈ। ਇਹ ਜਾਂ ਤਾਂ ਇੱਕ ਡੇਟਾਬੇਸ ਫਾਇਰਵਾਲ ਜਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਉੱਤੇ DBMS ਬਣਾਇਆ ਗਿਆ ਹੈ।

ਵਪਾਰਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੱਧਰ DBMSs ਵਿੱਚ ਆਡਿਟਿੰਗ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਪਰ ਓਪਨ ਸੋਰਸ ਵਿੱਚ - ਹਮੇਸ਼ਾ ਨਹੀਂ। PostgreSQL ਵਿੱਚ ਕੀ ਹੈ:

• ਡਿਫਾਲਟ ਲੌਗ - ਬਿਲਟ-ਇਨ ਲੌਗਿੰਗ;
• ਐਕਸਟੈਂਸ਼ਨਾਂ: pgaudit - ਜੇਕਰ ਤੁਹਾਡੇ ਲਈ ਡਿਫਾਲਟ ਲੌਗਿੰਗ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ।

ਵੀਡੀਓ ਵਿੱਚ ਰਿਪੋਰਟ ਵਿੱਚ ਜੋੜੋ:

"ਮੂਲ ਸਟੇਟਮੈਂਟ ਲੌਗਿੰਗ log_statement = all ਦੇ ਨਾਲ ਇੱਕ ਮਿਆਰੀ ਲੌਗਿੰਗ ਸਹੂਲਤ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਇਹ ਨਿਗਰਾਨੀ ਅਤੇ ਹੋਰ ਵਰਤੋਂ ਲਈ ਸਵੀਕਾਰਯੋਗ ਹੈ, ਪਰ ਆਡਿਟਿੰਗ ਲਈ ਲੋੜੀਂਦੇ ਵੇਰਵੇ ਦਾ ਪੱਧਰ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਡੇਟਾਬੇਸ 'ਤੇ ਕੀਤੇ ਗਏ ਸਾਰੇ ਕਾਰਜਾਂ ਦੀ ਸੂਚੀ ਹੋਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।

ਖਾਸ ਕਥਨਾਂ ਨੂੰ ਲੱਭਣਾ ਵੀ ਸੰਭਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਆਡੀਟਰ ਲਈ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ।

ਸਟੈਂਡਰਡ ਲੌਗਿੰਗ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਨੇ ਕੀ ਬੇਨਤੀ ਕੀਤੀ ਹੈ, ਜਦੋਂ ਕਿ pgAudit ਉਹਨਾਂ ਵੇਰਵਿਆਂ 'ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦਾ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਨੇ ਪੁੱਛਗਿੱਛ ਕੀਤੀ ਸੀ।

ਉਦਾਹਰਨ ਲਈ, ਆਡੀਟਰ ਇਹ ਤਸਦੀਕ ਕਰਨਾ ਚਾਹ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਖਾਸ ਸਾਰਣੀ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਬਣਾਈ ਗਈ ਸੀ।

ਇਹ ਬੁਨਿਆਦੀ ਆਡਿਟਿੰਗ ਅਤੇ ਗ੍ਰੈਪ ਦੇ ਨਾਲ ਇੱਕ ਸਧਾਰਨ ਕੰਮ ਵਾਂਗ ਜਾਪਦਾ ਹੈ, ਪਰ ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੀ (ਜਾਣ ਬੁੱਝ ਕੇ ਉਲਝਣ ਵਾਲੀ) ਉਦਾਹਰਣ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਹੈ:

ਕਰੋ$$
BEGIN
'ਟੇਬਲ ਆਯਾਤ ਬਣਾਓ' ਨੂੰ ਲਾਗੂ ਕਰੋ || 'ant_table(id int)';
END$$;

ਸਟੈਂਡਰਡ ਲੌਗਿੰਗ ਤੁਹਾਨੂੰ ਇਹ ਦੇਵੇਗਾ:

LOG: ਸਟੇਟਮੈਂਟ: DO $$
BEGIN
'ਟੇਬਲ ਆਯਾਤ ਬਣਾਓ' ਨੂੰ ਲਾਗੂ ਕਰੋ || 'ant_table(id int)';
END$$;

ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਦਿਲਚਸਪੀ ਦੀ ਸਾਰਣੀ ਨੂੰ ਲੱਭਣ ਲਈ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕੁਝ ਕੋਡ ਗਿਆਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਟੇਬਲਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਆਦਰਸ਼ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਸਾਰਣੀ ਦੇ ਨਾਮ ਦੁਆਰਾ ਖੋਜ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ।

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ pgAudit ਕੰਮ ਆਉਂਦਾ ਹੈ।

ਉਸੇ ਇੰਪੁੱਟ ਲਈ, ਇਹ ਲੌਗ ਵਿੱਚ ਇਹ ਆਉਟਪੁੱਟ ਪੈਦਾ ਕਰੇਗਾ:

ਆਡਿਟ: ਸੈਸ਼ਨ,33,1,ਫੰਕਸ਼ਨ,ਕਰੋ,,,"$$ ਕਰੋ
BEGIN
'ਟੇਬਲ ਆਯਾਤ ਬਣਾਓ' ਨੂੰ ਲਾਗੂ ਕਰੋ || 'ant_table(id int)';
END$$;"
ਆਡਿਟ: ਸੈਸ਼ਨ,33,2,DDL,ਸਾਰਣੀ ਬਣਾਓ,ਸਾਰਣੀ,public.important_table,CREATE TABLE important_table (id INT)

ਨਾ ਸਿਰਫ਼ DO ਬਲਾਕ ਲੌਗ ਕੀਤਾ ਗਿਆ ਹੈ, ਬਲਕਿ ਸਟੇਟਮੈਂਟ ਕਿਸਮ, ਵਸਤੂ ਦੀ ਕਿਸਮ, ਅਤੇ ਪੂਰੇ ਨਾਮ ਦੇ ਨਾਲ ਕ੍ਰੀਏਟ ਟੇਬਲ ਦਾ ਪੂਰਾ ਟੈਕਸਟ ਵੀ ਹੈ, ਜਿਸ ਨਾਲ ਖੋਜ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।

SELECT ਅਤੇ DML ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਲੌਗ ਕਰਨ ਵੇਲੇ, pgAudit ਨੂੰ ਸਟੇਟਮੈਂਟ ਵਿੱਚ ਹਵਾਲਾ ਦਿੱਤੇ ਹਰੇਕ ਰਿਸ਼ਤੇ ਲਈ ਇੱਕ ਵੱਖਰੀ ਐਂਟਰੀ ਲੌਗ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਕਿਸੇ ਖਾਸ ਸਾਰਣੀ ਨੂੰ ਛੂਹਣ ਵਾਲੇ ਸਾਰੇ ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਕਿਸੇ ਪਾਰਸਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ(*) ».

ਇਹ DBMS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਤ ਕਰੇਗਾ?

ਆਉ ਪੂਰੇ ਆਡਿਟਿੰਗ ਸਮਰੱਥ ਦੇ ਨਾਲ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ PostgreSQL ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ। ਆਉ ਸਾਰੇ ਮਾਪਦੰਡਾਂ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਡੇਟਾਬੇਸ ਲੌਗਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰੀਏ।

ਅਸੀਂ ਸੰਰਚਨਾ ਫਾਈਲ ਵਿੱਚ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਬਦਲਦੇ ਹਾਂ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਡੀਬੱਗ 5 ਮੋਡ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਹੈ.

postgresql.conf

log_destination = 'stderr'
ਲੌਗਿੰਗ_ਕਲੈਕਟਰ = ਚਾਲੂ
log_truncate_on_rotation = ਚਾਲੂ
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
ਡੀਬੱਗ_ਪ੍ਰਿੰਟ_ਪਾਰਸ = ਚਾਲੂ
debug_print_rewritten = ਚਾਲੂ
debug_print_plan = ਚਾਲੂ
debug_pretty_print = ਚਾਲੂ
log_checkpoints = ਚਾਲੂ
log_connections = ਚਾਲੂ
log_disconnections = ਚਾਲੂ
log_duration = ਚਾਲੂ
log_hostname = ਚਾਲੂ
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%

CPU
72%
91%

ਟੈਸਟ 1 (50 ਕਨੈਕਸ਼ਨ)

10 ਮਿੰਟਾਂ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਦੀ ਸੰਖਿਆ
74169
32445

ਲੈਣ-ਦੇਣ/ਸਕਿੰ
123
54

ਔਸਤ ਲੇਟੈਂਸੀ
405 ਮੀ
925 ਮੀ

ਟੈਸਟ 2 (150 ਦੇ ਨਾਲ 100 ਕੁਨੈਕਸ਼ਨ)

10 ਮਿੰਟਾਂ ਵਿੱਚ ਲੈਣ-ਦੇਣ ਦੀ ਸੰਖਿਆ
81727
31429

ਲੈਣ-ਦੇਣ/ਸਕਿੰ
136
52

ਔਸਤ ਲੇਟੈਂਸੀ
550 ਮੀ
1432 ਮੀ

ਆਕਾਰ ਬਾਰੇ

DB ਆਕਾਰ
2251 ਐਮ.ਬੀ.
2262 ਐਮ.ਬੀ.

ਡਾਟਾਬੇਸ ਲਾਗ ਦਾ ਆਕਾਰ
0 ਮੈਬਾ
4587 ਮੈਬਾ

ਤਲ ਲਾਈਨ: ਇੱਕ ਪੂਰਾ ਆਡਿਟ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ। ਆਡਿਟ ਦਾ ਡੇਟਾ ਡੇਟਾਬੇਸ ਵਿੱਚ ਡੇਟਾ ਜਿੰਨਾ ਵੱਡਾ ਹੋਵੇਗਾ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਵੱਧ। ਲੌਗਿੰਗ ਦੀ ਮਾਤਰਾ ਜੋ ਕਿ ਇੱਕ DBMS ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਹੈ।

ਆਉ ਹੋਰ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਵੇਖੀਏ:

• ਗਤੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਬਦਲਦੀ: ਲੌਗਿੰਗ ਤੋਂ ਬਿਨਾਂ - 43,74 ਸਕਿੰਟ, ਲੌਗਿੰਗ ਦੇ ਨਾਲ - 53,23 ਸਕਿੰਟ।
• RAM ਅਤੇ CPU ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਨੁਕਸਾਨ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਆਡਿਟ ਫਾਈਲ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਉਤਪਾਦਕਤਾ ਵਿੱਚ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ.

ਜਿਵੇਂ ਕਿ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਹੈ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਪ੍ਰਦਰਸ਼ਨ ਥੋੜ੍ਹਾ ਵਿਗੜ ਜਾਵੇਗਾ।

ਆਡਿਟ ਵਾਲੇ ਕਾਰਪੋਰੇਸ਼ਨਾਂ ਵਿੱਚ ਇਹ ਹੋਰ ਵੀ ਮੁਸ਼ਕਲ ਹੈ:

• ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਹੈ;
• ਆਡਿਟਿੰਗ ਦੀ ਲੋੜ ਸਿਰਫ਼ SIEM ਵਿੱਚ syslog ਦੁਆਰਾ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਫਾਈਲਾਂ ਵਿੱਚ ਵੀ ਹੈ: ਜੇਕਰ syslog ਨਾਲ ਕੁਝ ਵਾਪਰਦਾ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਦੇ ਨੇੜੇ ਇੱਕ ਫਾਈਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਹੈ;
• ਆਡਿਟਿੰਗ ਲਈ ਇੱਕ ਵੱਖਰੀ ਸ਼ੈਲਫ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ I/O ਡਿਸਕਾਂ ਨੂੰ ਬਰਬਾਦ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ, ਕਿਉਂਕਿ ਇਹ ਬਹੁਤ ਸਾਰੀ ਥਾਂ ਲੈਂਦਾ ਹੈ;
• ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਸੂਚਨਾ ਸੁਰੱਖਿਆ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਹਰ ਥਾਂ GOST ਮਿਆਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਰਾਜ ਦੀ ਪਛਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ.

ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨਾ

ਆਉ ਉਹਨਾਂ ਤਕਨੀਕਾਂ ਨੂੰ ਵੇਖੀਏ ਜੋ ਡੇਟਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਅਤੇ ਇਸ ਨੂੰ ਵਪਾਰਕ DBMS ਅਤੇ ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਐਕਸੈਸ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਵਰਤ ਸਕਦੇ ਹੋ:

1. ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਫੰਕਸ਼ਨਾਂ (ਰੈਪਿੰਗ) ਦੀ ਏਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਗੁੰਝਲਦਾਰਤਾ - ਅਰਥਾਤ, ਵੱਖਰੇ ਟੂਲ ਅਤੇ ਉਪਯੋਗਤਾਵਾਂ ਜੋ ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਸੱਚ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਨਾ ਤਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਨਾ ਹੀ ਮੁੜ-ਫੈਕਟਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਕਦੇ-ਕਦਾਈਂ ਘੱਟੋ-ਘੱਟ DBMS ਪਾਸੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਲਾਇਸੈਂਸ ਪਾਬੰਦੀਆਂ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਤਰਕ ਦਾ ਤਰਕ ਵਿਧੀ ਅਤੇ ਫੰਕਸ਼ਨ ਪੱਧਰ 'ਤੇ ਬਿਲਕੁਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
2. ਕਤਾਰਾਂ (RLS) ਦੁਆਰਾ ਡੇਟਾ ਦੀ ਦਿੱਖ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾ ਇੱਕ ਸਾਰਣੀ ਨੂੰ ਦੇਖਦੇ ਹਨ, ਪਰ ਇਸ ਵਿੱਚ ਕਤਾਰਾਂ ਦੀ ਇੱਕ ਵੱਖਰੀ ਰਚਨਾ, ਯਾਨੀ, ਕਤਾਰ ਪੱਧਰ 'ਤੇ ਕਿਸੇ ਨੂੰ ਕੁਝ ਨਹੀਂ ਦਿਖਾਇਆ ਜਾ ਸਕਦਾ।
3. ਪ੍ਰਦਰਸ਼ਿਤ ਡੇਟਾ (ਮਾਸਕਿੰਗ) ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਾਰਣੀ ਦੇ ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਉਪਭੋਗਤਾ ਜਾਂ ਤਾਂ ਡੇਟਾ ਜਾਂ ਸਿਰਫ ਤਾਰੇ ਵੇਖਦੇ ਹਨ, ਯਾਨੀ ਕੁਝ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਜਾਣਕਾਰੀ ਬੰਦ ਹੋ ਜਾਵੇਗੀ। ਤਕਨਾਲੋਜੀ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਸ ਉਪਭੋਗਤਾ ਨੂੰ ਉਹਨਾਂ ਦੇ ਪਹੁੰਚ ਪੱਧਰ ਦੇ ਆਧਾਰ 'ਤੇ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।
4. ਸੁਰੱਖਿਆ DBA/ਐਪਲੀਕੇਸ਼ਨ DBA/DBA ਪਹੁੰਚ ਨਿਯੰਤਰਣ, ਨਾ ਕਿ, DBMS ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਬਾਰੇ ਹੈ, ਯਾਨੀ ਕਿ, ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਆ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਡਾਟਾਬੇਸ ਪ੍ਰਸ਼ਾਸਕਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਸ਼ਾਸਕਾਂ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਅਜਿਹੀਆਂ ਕੁਝ ਤਕਨੀਕਾਂ ਹਨ, ਪਰ ਵਪਾਰਕ DBMS ਵਿੱਚ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਹਨ। ਉਹਨਾਂ ਦੀ ਜ਼ਰੂਰਤ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਉਪਭੋਗਤਾ ਹੁੰਦੇ ਹਨ.
5. ਫਾਈਲ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਫਾਈਲਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨਾ। ਤੁਸੀਂ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਅਧਿਕਾਰ ਅਤੇ ਪਹੁੰਚ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦੇ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਹਰੇਕ ਪ੍ਰਸ਼ਾਸਕ ਕੋਲ ਸਿਰਫ ਲੋੜੀਂਦੇ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਹੋਵੇ।
6. ਲਾਜ਼ਮੀ ਪਹੁੰਚ ਅਤੇ ਮੈਮੋਰੀ ਕਲੀਅਰਿੰਗ - ਇਹ ਤਕਨੀਕਾਂ ਘੱਟ ਹੀ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
7. DBMS ਤੋਂ ਸਿੱਧਾ ਐਂਡ-ਟੂ-ਐਂਡ ਏਨਕ੍ਰਿਪਸ਼ਨ ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਦੇ ਨਾਲ ਕਲਾਇੰਟ-ਸਾਈਡ ਇਨਕ੍ਰਿਪਸ਼ਨ ਹੈ।
8. ਡਾਟਾ ਇਨਕ੍ਰਿਪਸ਼ਨ। ਉਦਾਹਰਨ ਲਈ, ਕਾਲਮ ਐਨਕ੍ਰਿਪਸ਼ਨ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜੋ ਡੇਟਾਬੇਸ ਦੇ ਇੱਕ ਸਿੰਗਲ ਕਾਲਮ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ।

ਇਹ DBMS ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ?

ਆਉ PostgreSQL ਵਿੱਚ ਕਾਲਮ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਉਦਾਹਰਨ ਵੇਖੀਏ। ਇੱਥੇ ਇੱਕ pgcrypto ਮੋਡੀਊਲ ਹੈ, ਇਹ ਤੁਹਾਨੂੰ ਚੁਣੇ ਹੋਏ ਖੇਤਰਾਂ ਨੂੰ ਐਨਕ੍ਰਿਪਟਡ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਦੋਂ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਿਰਫ ਕੁਝ ਡੇਟਾ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ। ਏਨਕ੍ਰਿਪਟਡ ਖੇਤਰਾਂ ਨੂੰ ਪੜ੍ਹਨ ਲਈ, ਕਲਾਇੰਟ ਇੱਕ ਡੀਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਡੇਟਾ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਕੁੰਜੀ ਤੋਂ ਬਿਨਾਂ, ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਡੇਟਾ ਨਾਲ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

ਚਲੋ pgcrypto ਨਾਲ ਟੈਸਟ ਕਰੀਏ. ਆਉ ਏਨਕ੍ਰਿਪਟਡ ਡੇਟਾ ਅਤੇ ਨਿਯਮਤ ਡੇਟਾ ਦੇ ਨਾਲ ਇੱਕ ਸਾਰਣੀ ਬਣਾਈਏ। ਹੇਠਾਂ ਟੇਬਲ ਬਣਾਉਣ ਲਈ ਕਮਾਂਡਾਂ ਹਨ, ਪਹਿਲੀ ਲਾਈਨ ਵਿੱਚ ਇੱਕ ਉਪਯੋਗੀ ਕਮਾਂਡ ਹੈ - ਡੀਬੀਐਮਐਸ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਨਾਲ ਖੁਦ ਐਕਸਟੈਂਸ਼ਨ ਬਣਾਉਣਾ:

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

ਸਟੌਪਵਾਚ ਚਾਲੂ ਹੈ।

  id | ਟੈਕਸਟ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 ms

ਏਨਕ੍ਰਿਪਸ਼ਨ ਫੰਕਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਟੇਬਲ ਤੋਂ ਚੋਣ:

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

ਸਟੌਪਵਾਚ ਚਾਲੂ ਹੈ।

  id | ਡੀਕ੍ਰਿਪਟ | ਡੀਕ੍ਰਿਪਟ
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 ਲਾਈਨਾਂ)

ਸਮਾਂ: 50,203 ms

ਟੈਸਟ ਦੇ ਨਤੀਜੇ:

 
ਇਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਿਨਾਂ
Pgcrypto (ਡਿਕ੍ਰਿਪਟ)

ਨਮੂਨਾ 1000 ਕਤਾਰਾਂ
1,386 ਮੀ
50,203 ਮੀ

CPU
15%
35%

ਰੈਮ
 
+ 5%

ਐਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ। ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਸਮਾਂ ਵਧਿਆ ਹੈ, ਕਿਉਂਕਿ ਏਨਕ੍ਰਿਪਟ ਕੀਤੇ ਡੇਟਾ ਦੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਓਪਰੇਸ਼ਨਾਂ (ਅਤੇ ਡਿਕ੍ਰਿਪਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਤਰਕ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ) ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਭਾਵ, ਕੁਝ ਡੇਟਾ ਵਾਲੇ ਸਾਰੇ ਕਾਲਮਾਂ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਦਾ ਵਿਚਾਰ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਕਮੀ ਨਾਲ ਭਰਪੂਰ ਹੈ।

ਹਾਲਾਂਕਿ, ਏਨਕ੍ਰਿਪਸ਼ਨ ਇੱਕ ਸਿਲਵਰ ਬੁਲੇਟ ਨਹੀਂ ਹੈ ਜੋ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ। ਡੇਟਾ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਅਤੇ ਸੰਚਾਰਿਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਡੀਕ੍ਰਿਪਟਡ ਡੇਟਾ ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ ਸਰਵਰ 'ਤੇ ਸਥਿਤ ਹਨ। ਇਸ ਲਈ, ਕੁੰਜੀਆਂ ਨੂੰ ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਦੁਆਰਾ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸ ਕੋਲ ਡਾਟਾਬੇਸ ਸਰਵਰ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ।

ਜਦੋਂ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪੂਰੇ ਕਾਲਮ ਲਈ ਇੱਕ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ (ਭਾਵੇਂ ਸਾਰਿਆਂ ਲਈ ਨਹੀਂ, ਪਰ ਇੱਕ ਸੀਮਤ ਸਮੂਹ ਦੇ ਗਾਹਕਾਂ ਲਈ), ਇਹ ਹਮੇਸ਼ਾ ਚੰਗਾ ਅਤੇ ਸਹੀ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਉਹਨਾਂ ਨੇ ਐਂਡ-ਟੂ-ਐਂਡ ਏਨਕ੍ਰਿਪਸ਼ਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, DBMS ਵਿੱਚ ਉਹਨਾਂ ਨੇ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਡੇਟਾ ਨੂੰ ਏਨਕ੍ਰਿਪਟ ਕਰਨ ਦੇ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਉਹੀ ਕੀ-ਵਾਲਟ ਸਟੋਰੇਜ ਦਿਖਾਈ ਦਿੱਤੇ - ਵੱਖਰੇ ਉਤਪਾਦ ਜੋ DBMS 'ਤੇ ਕੁੰਜੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਪਾਸੇ.

MongoDB ਵਿੱਚ ਅਜਿਹੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ

ਵਪਾਰਕ ਅਤੇ ਓਪਨ ਸੋਰਸ DBMS ਵਿੱਚ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਫੰਕਸ਼ਨ
ਟਾਈਪ ਕਰੋ
ਪਾਸਵਰਡ ਨੀਤੀ
ਆਡਿਟ
ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਕਾਰਜਾਂ ਦੇ ਸਰੋਤ ਕੋਡ ਦੀ ਰੱਖਿਆ ਕਰਨਾ
ਆਰ.ਐਲ.ਐੱਸ
ਇੰਕ੍ਰਿਪਸ਼ਨ

ਓਰੇਕਲ
ਵਪਾਰਕ
+
+
+
+
+

MsSql
ਵਪਾਰਕ
+
+
+
+
+

ਜਟੋਬਾ
ਵਪਾਰਕ
+
+
+
+
ਇਕਸਟੈਨਸ਼ਨ

PostgreSQL
ਮੁਫ਼ਤ
ਇਕਸਟੈਨਸ਼ਨ
ਇਕਸਟੈਨਸ਼ਨ
-
+
ਇਕਸਟੈਨਸ਼ਨ

ਮੋਂਗੋਡੀਬੀ
ਮੁਫ਼ਤ
-
+
-
-
ਸਿਰਫ MongoDB Enterprise ਵਿੱਚ ਉਪਲਬਧ ਹੈ

ਸਾਰਣੀ ਪੂਰੀ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ, ਪਰ ਸਥਿਤੀ ਇਹ ਹੈ: ਵਪਾਰਕ ਉਤਪਾਦਾਂ ਵਿੱਚ, ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਓਪਨ ਸੋਰਸ ਵਿੱਚ, ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਸੁਰੱਖਿਆ ਲਈ ਕੁਝ ਕਿਸਮ ਦੇ ਐਡ-ਆਨ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਫੰਕਸ਼ਨ ਗੁੰਮ ਹਨ. , ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਕੁਝ ਜੋੜਨਾ ਪੈਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਪਾਸਵਰਡ ਨੀਤੀਆਂ - PostgreSQL ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਖ-ਵੱਖ ਐਕਸਟੈਂਸ਼ਨਾਂ ਹਨ (1, 2, 3, 4, 5), ਜੋ ਪਾਸਵਰਡ ਨੀਤੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਪਰ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਘਰੇਲੂ ਕਾਰਪੋਰੇਟ ਹਿੱਸੇ ਦੀਆਂ ਸਾਰੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਨਹੀਂ ਹੈ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਕਿਤੇ ਵੀ ਲੋੜ ਹੈ? ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਖਾਸ DBMS ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਉਹ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹਨ ਜੋ ਗਾਹਕ ਨੂੰ ਲੋੜੀਂਦੇ ਹਨ।

ਫਿਰ ਤੁਸੀਂ ਤੀਜੀ-ਧਿਰ ਦੇ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਵੱਖ-ਵੱਖ DBMSs ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, Crypto DB ਜਾਂ Garda DB. ਜੇਕਰ ਅਸੀਂ ਘਰੇਲੂ ਹਿੱਸੇ ਦੇ ਹੱਲਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਉਹ ਓਪਨ ਸੋਰਸ ਨਾਲੋਂ GOSTs ਬਾਰੇ ਬਿਹਤਰ ਜਾਣਦੇ ਹਨ।

ਦੂਸਰਾ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਹ ਲਿਖੋ, ਪ੍ਰਕਿਰਿਆ ਪੱਧਰ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਡੇਟਾ ਐਕਸੈਸ ਅਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਇਹ ਸੱਚ ਹੈ, ਇਹ GOST ਨਾਲ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੋਵੇਗਾ. ਪਰ ਆਮ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਲੋੜ ਅਨੁਸਾਰ ਡੇਟਾ ਨੂੰ ਲੁਕਾ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਇੱਕ DBMS ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ, ਫਿਰ ਇਸਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦੇ ਹੋ, ਬਿਲਕੁਲ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ। ਉਸੇ ਸਮੇਂ, ਤੁਰੰਤ ਇਸ ਬਾਰੇ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇਹਨਾਂ ਐਲਗੋਰਿਦਮਾਂ ਦੀ ਸੁਰੱਖਿਆ ਕਿਵੇਂ ਕਰੋਗੇ। ਸਾਡੀ ਰਾਏ ਵਿੱਚ, ਇਹ DBMS ਪੱਧਰ 'ਤੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰੇਗਾ.

ਇਹ ਰਿਪੋਰਟ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਸੀ @ਡਾਟਾਬੇਸ ਮੀਟਅੱਪ Mail.ru ਕਲਾਉਡ ਹੱਲ਼ ਦੁਆਰਾ। ਦੇਖੋ видео ਹੋਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਟੈਲੀਗ੍ਰਾਮ 'ਤੇ ਇਵੈਂਟ ਘੋਸ਼ਣਾਵਾਂ ਦੇ ਗਾਹਕ ਬਣੋ Mail.ru ਗਰੁੱਪ 'ਤੇ ਕੁਬਰਨੇਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ.

ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਕੀ ਪੜ੍ਹਨਾ ਹੈ:

1. Ceph ਤੋਂ ਵੱਧ: MCS ਕਲਾਉਡ ਬਲਾਕ ਸਟੋਰੇਜ.
2. ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਡੇਟਾਬੇਸ ਦੀ ਚੋਣ ਕਿਵੇਂ ਕਰੀਏ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਚੋਣ ਨਾ ਕਰਨੀ ਪਵੇ.

ਸਰੋਤ: www.habr.com