Tên tôi là Denis Rozhkov, tôi là trưởng bộ phận phát triển phần mềm của công ty Gazinformservice, trong nhóm sản phẩm . Pháp luật và các quy định của công ty áp đặt các yêu cầu nhất định về tính bảo mật của việc lưu trữ dữ liệu. Không ai muốn bên thứ ba có quyền truy cập vào thông tin bí mật, vì vậy các vấn đề sau rất quan trọng đối với bất kỳ dự án nào: nhận dạng và xác thực, quản lý quyền truy cập dữ liệu, đảm bảo tính toàn vẹn của thông tin trong hệ thống, ghi lại các sự kiện bảo mật. Vì vậy, tôi muốn nói về một số điểm thú vị liên quan đến bảo mật DBMS.
Bài viết được chuẩn bị dựa trên bài phát biểu tại được tổ chức . Nếu không muốn đọc, bạn có thể xem:
Bài viết sẽ có ba phần:
- Cách bảo mật các kết nối.
- Kiểm tra hành động là gì và cách ghi lại những gì đang xảy ra ở phía cơ sở dữ liệu và kết nối với nó.
- Cách bảo vệ dữ liệu trong cơ sở dữ liệu và những công nghệ hiện có cho việc này.
Ba thành phần của bảo mật DBMS: bảo vệ kết nối, kiểm tra hoạt động và bảo vệ dữ liệu
Bảo mật kết nối của bạn
Bạn có thể kết nối với cơ sở dữ liệu trực tiếp hoặc gián tiếp thông qua các ứng dụng web. Theo quy định, người dùng doanh nghiệp, tức là người làm việc với DBMS, tương tác gián tiếp với nó.
Trước khi nói về việc bảo vệ kết nối, bạn cần trả lời các câu hỏi quan trọng xác định cách thức cấu trúc các biện pháp bảo mật:
- Một người dùng doanh nghiệp có tương đương với một người dùng DBMS không?
- liệu quyền truy cập vào dữ liệu DBMS chỉ được cung cấp thông qua API mà bạn kiểm soát hay liệu các bảng có được truy cập trực tiếp hay không;
- liệu DBMS có được phân bổ cho một phân đoạn được bảo vệ riêng biệt hay không, ai tương tác với nó và bằng cách nào;
- liệu các lớp tổng hợp/proxy và lớp trung gian có được sử dụng hay không, điều này có thể thay đổi thông tin về cách kết nối được xây dựng và ai đang sử dụng cơ sở dữ liệu.
Bây giờ hãy xem những công cụ nào có thể được sử dụng để bảo mật kết nối:
- Sử dụng các giải pháp lớp tường lửa cơ sở dữ liệu. Ở mức tối thiểu, một lớp bảo vệ bổ sung sẽ tăng tính minh bạch về những gì đang diễn ra trong DBMS và ở mức tối đa, bạn sẽ có thể cung cấp khả năng bảo vệ dữ liệu bổ sung.
- Sử dụng chính sách mật khẩu. Việc sử dụng chúng phụ thuộc vào cách kiến trúc của bạn được xây dựng. Trong mọi trường hợp, một mật khẩu trong tệp cấu hình của ứng dụng web kết nối với DBMS là không đủ để bảo vệ. Có một số công cụ DBMS cho phép bạn kiểm soát việc người dùng và mật khẩu có yêu cầu cập nhật hay không.
Bạn có thể đọc thêm về chức năng xếp hạng của người dùng , bạn cũng có thể tìm hiểu về Đánh giá lỗ hổng MS SQL .
- Làm phong phú thêm bối cảnh của buổi học với những thông tin cần thiết. Nếu phiên không rõ ràng, bạn không hiểu ai đang làm việc trong DBMS trong khuôn khổ của nó, bạn có thể, trong khuôn khổ hoạt động đang được thực hiện, thêm thông tin về ai đang làm gì và tại sao. Thông tin này có thể được nhìn thấy trong kiểm toán.
- Định cấu hình SSL nếu bạn không có sự phân tách mạng giữa DBMS và người dùng cuối; nó không nằm trong một VLAN riêng. Trong những trường hợp như vậy, bắt buộc phải bảo vệ kênh giữa người tiêu dùng và chính DBMS. Các công cụ bảo mật cũng có sẵn ở dạng nguồn mở.
Điều này sẽ ảnh hưởng đến hiệu suất của DBMS như thế nào?
Chúng ta hãy xem ví dụ về PostgreSQL để xem SSL ảnh hưởng như thế nào đến tải CPU, tăng thời gian và giảm TPS cũng như liệu SSL có tiêu tốn quá nhiều tài nguyên nếu bạn kích hoạt nó hay không.
Tải PostgreSQL bằng pgbench là một chương trình đơn giản để chạy thử nghiệm hiệu năng. Nó thực thi một chuỗi lệnh lặp đi lặp lại, có thể trong các phiên cơ sở dữ liệu song song, sau đó tính toán tốc độ giao dịch trung bình.
Kiểm tra 1 không có SSL và sử dụng SSL - kết nối được thiết lập cho mỗi giao dịch:
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"Kiểm tra 2 không có SSL và sử dụng SSL — tất cả các giao dịch được thực hiện trong một kết nối:
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"Các thiết lập khác:
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/50000Kết quả kiểm tra:
KHÔNG CÓ SSL
SSL
Một kết nối được thiết lập cho mọi giao dịch
độ trễ trung bình
171.915 ms
187.695 ms
tps bao gồm cả việc thiết lập các kết nối
58.168112
53.278062
tps không bao gồm các kết nối thiết lập
64.084546
58.725846
CPU
24%
28%
Tất cả các giao dịch được thực hiện trong một kết nối
độ trễ trung bình
6.722 ms
6.342 ms
tps bao gồm cả việc thiết lập các kết nối
1587.657278
1576.792883
tps không bao gồm các kết nối thiết lập
1588.380574
1577.694766
CPU
17%
21%
Ở mức tải nhẹ, ảnh hưởng của SSL có thể so sánh với sai số đo. Nếu lượng dữ liệu được truyền rất lớn, tình hình có thể khác. Nếu chúng tôi thiết lập một kết nối cho mỗi giao dịch (điều này rất hiếm, thường kết nối được chia sẻ giữa những người dùng), thì bạn có số lượng kết nối/ngắt kết nối lớn, tác động có thể lớn hơn một chút. Tức là có thể có rủi ro làm giảm hiệu suất, tuy nhiên, sự khác biệt không lớn đến mức không sử dụng biện pháp bảo vệ.
Xin lưu ý rằng có sự khác biệt lớn nếu bạn so sánh các chế độ vận hành: bạn đang làm việc trong cùng một phiên hoặc trong các chế độ khác nhau. Điều này có thể hiểu được: tài nguyên được dành cho việc tạo mỗi kết nối.
Chúng tôi gặp trường hợp khi kết nối Zabbix ở chế độ tin cậy, tức là md5 không được kiểm tra, không cần xác thực. Sau đó khách hàng yêu cầu bật chế độ xác thực md5. Điều này đặt gánh nặng lên CPU và hiệu suất giảm xuống. Chúng tôi bắt đầu tìm cách tối ưu hóa. Một trong những giải pháp khả thi cho vấn đề này là thực hiện các hạn chế về mạng, tạo các VLAN riêng cho DBMS, thêm cài đặt để làm rõ ai đang kết nối từ đâu và xóa xác thực.Bạn cũng có thể tối ưu hóa cài đặt xác thực để giảm chi phí khi kích hoạt xác thực, nhưng nói chung, việc sử dụng các phương pháp xác thực khác nhau sẽ ảnh hưởng đến hiệu suất và yêu cầu phải tính đến các yếu tố này khi thiết kế sức mạnh tính toán của máy chủ (phần cứng) cho DBMS.
Kết luận: trong một số giải pháp, ngay cả những sắc thái nhỏ trong việc xác thực cũng có thể ảnh hưởng lớn đến dự án và thật tệ khi điều này chỉ trở nên rõ ràng khi được triển khai trong sản xuất.
Kiểm tra hành động
Kiểm toán có thể không chỉ DBMS. Kiểm toán là việc thu thập thông tin về những gì đang xảy ra ở các phân khúc khác nhau. Đây có thể là tường lửa cơ sở dữ liệu hoặc hệ điều hành mà DBMS được xây dựng trên đó.
Trong các DBMS cấp doanh nghiệp thương mại, mọi thứ đều ổn với việc kiểm tra, nhưng trong nguồn mở - không phải lúc nào cũng vậy. Đây là những gì PostgreSQL có:
- nhật ký mặc định - ghi nhật ký tích hợp;
- tiện ích mở rộng: pgaudit - nếu việc ghi nhật ký mặc định không đủ đối với bạn, bạn có thể sử dụng các cài đặt riêng để giải quyết một số vấn đề.
Bổ sung vào báo cáo trong video:
"Việc ghi nhật ký câu lệnh cơ bản có thể được cung cấp bởi cơ sở ghi nhật ký tiêu chuẩn với log_statement = all.
Điều này có thể chấp nhận được cho việc giám sát và các mục đích sử dụng khác nhưng không cung cấp mức độ chi tiết thường được yêu cầu cho việc kiểm tra.
Việc có một danh sách tất cả các hoạt động được thực hiện trên cơ sở dữ liệu là chưa đủ.
Cũng có thể tìm thấy các báo cáo cụ thể mà kiểm toán viên quan tâm.
Ghi nhật ký tiêu chuẩn hiển thị những gì người dùng yêu cầu, trong khi pgAudit tập trung vào chi tiết về những gì đã xảy ra khi cơ sở dữ liệu thực hiện truy vấn.
Ví dụ: kiểm toán viên có thể muốn xác minh rằng một bảng cụ thể đã được tạo trong khoảng thời gian bảo trì được ghi lại.
Đây có vẻ giống như một nhiệm vụ đơn giản với kiểm toán cơ bản và grep, nhưng điều gì sẽ xảy ra nếu bạn được đưa ra một ví dụ như thế này (cố tình gây nhầm lẫn):
LÀM $$
BEGIN
THỰC HIỆN 'TẠO BẢNG nhập khẩu' || 'ant_table(id int)';
KẾT THÚC$$;
Ghi nhật ký tiêu chuẩn sẽ cung cấp cho bạn điều này:
LOG: tuyên bố: LÀM $$
BEGIN
THỰC HIỆN 'TẠO BẢNG nhập khẩu' || 'ant_table(id int)';
KẾT THÚC$$;
Có vẻ như việc tìm kiếm bảng quan tâm có thể yêu cầu một số kiến thức về mã trong trường hợp bảng được tạo động.
Điều này không lý tưởng vì tốt hơn là bạn chỉ cần tìm kiếm theo tên bảng.
Đây là lúc pgAudit phát huy tác dụng.
Đối với cùng một đầu vào, nó sẽ tạo ra đầu ra này trong nhật ký:
KIỂM TOÁN: PHIÊN,33,1,CHỨC NĂNG,DO,,,"DO $$
BEGIN
THỰC HIỆN 'TẠO BẢNG nhập khẩu' || 'ant_table(id int)';
KẾT THÚC$$;"
KIỂM TOÁN: SESSION,33,2,DDL,TẠO BẢNG,BẢNG,public.important_table,TẠO BẢNG quan trọng_table (id INT)
Không chỉ khối DO được ghi lại mà toàn bộ nội dung của CREATE TABLE với loại câu lệnh, loại đối tượng và tên đầy đủ cũng được ghi lại, giúp việc tìm kiếm dễ dàng hơn.
Khi ghi nhật ký các câu lệnh SELECT và DML, pgAudit có thể được cấu hình để ghi nhật ký một mục nhập riêng cho từng mối quan hệ được tham chiếu trong câu lệnh.
Không cần phân tích cú pháp để tìm tất cả các câu lệnh chạm vào một bảng cụ thể () ».
Điều này sẽ ảnh hưởng đến hiệu suất của DBMS như thế nào?
Hãy chạy thử nghiệm với tính năng kiểm tra đầy đủ được kích hoạt và xem điều gì xảy ra với hiệu suất của PostgreSQL. Hãy kích hoạt tính năng ghi nhật ký cơ sở dữ liệu tối đa cho tất cả các tham số.
Chúng ta hầu như không thay đổi gì trong file cấu hình, quan trọng nhất là bật chế độ debug5 để có được thông tin tối đa.
postgresql.conf
log_destination = 'stderr'
ghi nhật ký_collector = bật
log_truncate_on_rotation = bật
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = gỡ lỗi5
log_min_error_statement = gỡ lỗi5
log_min_duration_statement = 0
debug_print_parse = bật
debug_print_rewriting = bật
debug_print_plan = bật
debug_pretty_print = bật
log_checkpoint = bật
log_connections = bật
log_disconnections = bật
log_duration = bật
log_hostname = bật
log_lock_waits = bật
log_replication_commands = bật
log_temp_files = 0
log_timezone = 'Châu Âu/Moscow'
Trên hệ quản trị cơ sở dữ liệu PostgreSQL có thông số 1 CPU, 2,8 GHz, RAM 2 GB, ổ cứng 40 GB, chúng tôi tiến hành ba bài kiểm tra tải bằng các lệnh:
$ 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 benchmarkKết quả kiểm tra:
Không đăng nhập
Với việc ghi nhật ký
Tổng thời gian điền cơ sở dữ liệu
43,74 giây
53,23 giây
Ram
24%
40%
CPU
72%
91%
Kiểm tra 1 (50 kết nối)
Số lượng giao dịch trong 10 phút
74169
32445
Giao dịch/giây
123
54
Độ trễ trung bình
405 ms
925 ms
Kiểm tra 2 (150 kết nối với 100 kết nối có thể)
Số lượng giao dịch trong 10 phút
81727
31429
Giao dịch/giây
136
52
Độ trễ trung bình
550 ms
1432 ms
Về kích thước
kích thước cơ sở dữ liệu
MB MB
MB MB
Kích thước nhật ký cơ sở dữ liệu
0 MB
4587 MB
Điểm mấu chốt: kiểm toán đầy đủ là không tốt lắm. Dữ liệu từ quá trình kiểm tra sẽ lớn bằng chính dữ liệu trong cơ sở dữ liệu hoặc thậm chí nhiều hơn. Số lượng bản ghi được tạo ra khi làm việc với DBMS là một vấn đề thường gặp trong quá trình sản xuất.
Hãy xem xét các thông số khác:
- Tốc độ không thay đổi nhiều: không ghi nhật ký - 43,74 giây, có ghi nhật ký - 53,23 giây.
- Hiệu suất RAM và CPU sẽ bị ảnh hưởng vì bạn cần tạo tệp kiểm tra. Điều này cũng đáng chú ý trong năng suất.
Khi số lượng kết nối tăng lên, đương nhiên hiệu suất sẽ giảm đi một chút.
Ở những công ty có kiểm toán, điều đó thậm chí còn khó khăn hơn:
- có rất nhiều dữ liệu;
- Việc kiểm tra không chỉ cần thiết thông qua syslog trong SIEM mà còn trong các tệp: nếu có điều gì đó xảy ra với syslog, thì phải có một tệp gần cơ sở dữ liệu để lưu dữ liệu;
- cần có một kệ riêng để kiểm tra để không lãng phí các đĩa I/O vì nó chiếm nhiều dung lượng;
- Điều xảy ra là ở mọi nơi nhân viên bảo mật thông tin đều cần tiêu chuẩn GOST, họ yêu cầu nhận dạng nhà nước.
Hạn chế quyền truy cập vào dữ liệu
Hãy xem xét các công nghệ được sử dụng để bảo vệ dữ liệu và truy cập dữ liệu đó trong các DBMS thương mại và nguồn mở.
Bạn thường có thể sử dụng những gì:
- Mã hóa và làm xáo trộn các thủ tục và chức năng (Gói) - nghĩa là các công cụ và tiện ích riêng biệt khiến mã có thể đọc được không thể đọc được. Đúng, sau đó nó không thể thay đổi cũng như không thể tái cấu trúc lại. Cách tiếp cận này đôi khi được yêu cầu ít nhất ở phía DBMS - logic của các hạn chế cấp phép hoặc logic ủy quyền được mã hóa chính xác ở cấp độ thủ tục và chức năng.
- Giới hạn khả năng hiển thị dữ liệu theo hàng (RLS) là khi những người dùng khác nhau nhìn thấy một bảng nhưng thành phần các hàng trong đó khác nhau, tức là không thể hiển thị nội dung nào đó cho ai đó ở cấp hàng.
- Chỉnh sửa dữ liệu được hiển thị (Masking) là khi người dùng trong một cột của bảng nhìn thấy dữ liệu hoặc chỉ nhìn thấy dấu hoa thị, tức là đối với một số người dùng, thông tin sẽ bị đóng. Công nghệ xác định người dùng nào được hiển thị những gì dựa trên cấp độ truy cập của họ.
- Bảo mật DBA/Ứng dụng Kiểm soát truy cập DBA/DBA nói đúng hơn là hạn chế quyền truy cập vào chính DBMS, nghĩa là nhân viên bảo mật thông tin có thể tách biệt khỏi quản trị viên cơ sở dữ liệu và quản trị viên ứng dụng. Có rất ít công nghệ như vậy trong mã nguồn mở nhưng lại có rất nhiều trong các DBMS thương mại. Chúng cần thiết khi có nhiều người dùng có quyền truy cập vào máy chủ.
- Hạn chế quyền truy cập vào các tệp ở cấp hệ thống tệp. Bạn có thể cấp quyền và đặc quyền truy cập vào các thư mục để mỗi quản trị viên chỉ có quyền truy cập vào dữ liệu cần thiết.
- Truy cập bắt buộc và xóa bộ nhớ - những công nghệ này hiếm khi được sử dụng.
- Mã hóa đầu cuối trực tiếp từ DBMS là mã hóa phía máy khách với quản lý khóa ở phía máy chủ.
- Mã hóa dữ liệu. Ví dụ: mã hóa cột là khi bạn sử dụng cơ chế mã hóa một cột duy nhất của cơ sở dữ liệu.
Điều này ảnh hưởng như thế nào đến hiệu suất của DBMS?
Hãy xem ví dụ về mã hóa cột trong PostgreSQL. Có một mô-đun pgcrypto, nó cho phép bạn lưu trữ các trường đã chọn ở dạng mã hóa. Điều này rất hữu ích khi chỉ có một số dữ liệu có giá trị. Để đọc các trường được mã hóa, máy khách sẽ truyền khóa giải mã, máy chủ giải mã dữ liệu và trả lại cho máy khách. Nếu không có chìa khóa, không ai có thể làm gì với dữ liệu của bạn.
Hãy thử nghiệm với pgcrypto. Hãy tạo một bảng có dữ liệu được mã hóa và dữ liệu thông thường. Dưới đây là các lệnh tạo bảng, ngay dòng đầu tiên có một lệnh hữu ích - tự tạo tiện ích mở rộng bằng đăng ký 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'));Tiếp theo, hãy thử tạo mẫu dữ liệu từ mỗi bảng và xem thời gian thực hiện.
Chọn từ một bảng không có chức năng mã hóa:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtĐồng hồ bấm giờ đang bật.
id | văn bản1 | văn bản2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 dòng)
Thời gian: 1,386 ms
Lựa chọn từ một bảng có chức năng mã hóa:
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Đồng hồ bấm giờ đang bật.
id | giải mã | giải mã
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 dòng)
Thời gian: 50,203 ms
Kết quả kiểm tra:
Không có mã hóa
PGcrypto (giải mã)
Mẫu 1000 hàng
1,386 ms
50,203 ms
CPU
15%
35%
Ram
+ 5%
Mã hóa có tác động lớn đến hiệu suất. Có thể thấy rằng thời gian đã tăng lên, vì các hoạt động giải mã dữ liệu được mã hóa (và quá trình giải mã thường vẫn được gói trong logic của bạn) yêu cầu tài nguyên đáng kể. Nghĩa là, ý tưởng mã hóa tất cả các cột chứa một số dữ liệu sẽ làm giảm hiệu suất.
Tuy nhiên, mã hóa không phải là viên đạn bạc có thể giải quyết mọi vấn đề. Dữ liệu được giải mã và khóa giải mã trong quá trình giải mã và truyền dữ liệu được đặt trên máy chủ. Do đó, khóa có thể bị chặn bởi người có toàn quyền truy cập vào máy chủ cơ sở dữ liệu, chẳng hạn như quản trị viên hệ thống.
Khi có một khóa cho toàn bộ cột cho tất cả người dùng (ngay cả khi không phải cho tất cả, nhưng đối với các khách hàng thuộc một nhóm giới hạn), điều này không phải lúc nào cũng tốt và đúng. Đó là lý do tại sao họ bắt đầu thực hiện mã hóa đầu cuối, trong DBMS, họ bắt đầu xem xét các tùy chọn mã hóa dữ liệu ở phía máy khách và máy chủ, và các kho lưu trữ key-vault tương tự đó đã xuất hiện - các sản phẩm riêng biệt cung cấp khả năng quản lý khóa trên DBMS bên.
Các tính năng bảo mật trong DBMS thương mại và nguồn mở
Chức năng
Loại
Chính sách mật khẩu
Kiểm toán
Bảo vệ mã nguồn của thủ tục và chức năng
RLS
Encryption
Oracle
thương mại
+
+
+
+
+
MsSql
thương mại
+
+
+
+
+
thương mại
+
+
+
+
mở rộng
PostgreSQL
Miễn phí
mở rộng
mở rộng
-
+
mở rộng
MongoDb
Miễn phí
-
+
-
-
Chỉ có sẵn trong MongoDB Enterprise
Bảng này vẫn chưa hoàn chỉnh, nhưng tình hình là thế này: trong các sản phẩm thương mại, các vấn đề bảo mật đã được giải quyết từ lâu, trong mã nguồn mở, theo quy luật, một số loại tiện ích bổ sung được sử dụng để bảo mật, nhiều chức năng bị thiếu , đôi khi bạn phải thêm một cái gì đó. Ví dụ: chính sách mật khẩu - PostgreSQL có nhiều phần mở rộng khác nhau (, , , , ), thực hiện các chính sách mật khẩu, nhưng theo tôi, không có chính sách nào trong số đó đáp ứng được tất cả nhu cầu của phân khúc doanh nghiệp trong nước.
Phải làm gì nếu bạn không có thứ bạn cần ở bất cứ đâu? Ví dụ: bạn muốn sử dụng một DBMS cụ thể không có các chức năng mà khách hàng yêu cầu.
Sau đó, bạn có thể sử dụng các giải pháp của bên thứ ba hoạt động với các DBMS khác nhau, ví dụ: Crypto DB hoặc Garda DB. Nếu chúng ta đang nói về các giải pháp từ phân khúc nội địa, thì họ biết về GOST tốt hơn so với nguồn mở.
Tùy chọn thứ hai là tự viết những gì bạn cần, triển khai truy cập và mã hóa dữ liệu trong ứng dụng ở cấp quy trình. Đúng, sẽ khó khăn hơn với GOST. Nhưng nói chung, bạn có thể ẩn dữ liệu khi cần, đặt dữ liệu vào DBMS, sau đó truy xuất và giải mã khi cần, ngay ở cấp ứng dụng. Đồng thời, hãy nghĩ ngay đến cách bạn sẽ bảo vệ các thuật toán này trong ứng dụng. Theo quan điểm của chúng tôi, việc này nên được thực hiện ở cấp DBMS vì nó sẽ hoạt động nhanh hơn.
Báo cáo này lần đầu tiên được trình bày tại bởi Giải pháp đám mây Mail.ru. Nhìncác buổi biểu diễn khác và đăng ký nhận thông báo sự kiện trên Telegram .
Những gì khác để đọc về chủ đề này:
- .
- .
Nguồn: www.habr.com