Không có gì bí mật mà thông tin làm cho thế giới xung quanh hiện tại. Nếu một doanh nghiệp quan tâm đến tài sản trí tuệ của mình và mỗi nhân viên có thể dễ dàng có được thông tin cần thiết, doanh nghiệp có thể hy vọng vào sự phát triển. Nếu có sự hỗn loạn trong dữ liệu, doanh nghiệp sẽ thất bại dù có tinh thần đồng đội.
Trong bài viết này, chúng ta sẽ tìm hiểu các khái niệm cơ bản về bảo mật cơ sở dữ liệu và các ví dụ về bảo vệ thông tin trong Oracle. Trên thực tế, những kiến thức cơ bản về lý thuyết để bảo vệ thông tin trong cơ sở dữ liệu, mà chúng ta sẽ xem xét trong bài viết này, cũng sẽ hữu ích cho những người làm việc với các cơ sở dữ liệu khác.
Quyền truy cập
Trong hầu hết các công ty mà tôi từng làm việc, tất cả các quản trị viên và nhà phát triển đều có quyền truy cập đầy đủ vào cơ sở dữ liệu, cũng như nhân viên của bộ phận CNTT là một vị thần và có thể làm bất cứ điều gì họ muốn. Tại sao nó xảy ra? Có hai lý do cho điều này:
- Khi làm việc trong một bộ phận, các nhân viên có thể gặp nhau 8 giờ mỗi ngày và trở thành bạn bè. Làm thế nào họ không thể cấp quyền truy cập? Tình bạn là một chuyện nhưng kinh doanh là công việc.
- Việc cấp một số quyền truy cập hoặc sửa đổi một số cấu hình có thể yêu cầu một số đặc quyền. Đôi khi, quản trị viên nghĩ rằng lập trình viên cấu hình cài đặt tốt hơn. Do đó, chúng cung cấp cho lập trình viên các quyền truy cập không cần thiết. Thay vào đó, lập trình viên không được tham gia quản lý và không được có bất kỳ quyền nào đối với việc này.
Theo kinh nghiệm của tôi, vấn đề thứ hai rất phổ biến, do đó, chúng tôi sẽ phân tích chi tiết.
Khi phát triển chương trình cho cơ sở dữ liệu, lập trình viên biết mật khẩu siêu người dùng hoặc đơn giản là có quyền quản trị cơ sở dữ liệu. Điều này là không cần thiết và hoàn toàn không an toàn. Chỉ người quản trị cơ sở dữ liệu mới có đầy đủ quyền. Ngay cả trưởng phòng, giám đốc và những người bạn thân nhất cũng có thể có ít đặc quyền hơn.
Ví dụ, khi phát triển các chương trình, chỉ cần có quyền của chủ sở hữu lược đồ trong cơ sở dữ liệu Oracle lưu trữ các bảng làm việc là đủ. Các quyền này đủ để tạo bảng, gói, chỉ mục và các đối tượng khác, cũng như cấp quyền truy cập vào các đối tượng lược đồ cho người dùng khác. Bạn không cần quyền hệ thống để làm việc toàn thời gian.
Nếu không có người quản trị cơ sở dữ liệu toàn thời gian thì rất tệ. Sẽ tốt hơn khi có người chịu trách nhiệm về hiệu suất, tối ưu hóa và bảo mật cơ sở dữ liệu. Ít nhất, bạn cần chỉ định một lập trình viên chịu trách nhiệm về việc này và sẽ có độc quyền.
Theo thống kê, nhân viên của công ty làm mất dữ liệu thường xuyên nhất. Tuy nhiên, bất chấp thực tế này, hầu hết các công ty vẫn tiếp tục bỏ qua chủ đề này và các cơ sở dữ liệu khác nhau được lưu trữ trên đĩa khi truy cập miễn phí được bán ngay cả trong tàu điện ngầm.
Người dùng và vai trò
Có hai loại đối tượng để cấp quyền truy cập trong cơ sở dữ liệu:người dùng và vai trò. Vai trò là một số nhóm kết hợp những người dùng phải có các quyền tương tự. Ví dụ, tất cả các nhân viên kế toán có thể yêu cầu quyền truy cập vào các tài liệu tài chính. Để ngăn bạn cấp quyền cho từng kế toán viên, chúng tôi có thể kết hợp chúng thành một vai trò với quyền truy cập cần thiết.
Như bạn có thể thấy, nguyên tắc của các vai trò tương tự như các nhóm trong hệ điều hành Windows. Tuy nhiên, nó có một số khác biệt. Không phải không có lý do, cả ba kiểu đối tượng như người dùng, nhóm và vai trò đều có thể được triển khai trong cơ sở dữ liệu. Tuy nhiên, chỉ người dùng và vai trò được thực hiện trong hầu hết các cơ sở dữ liệu. Cần phải quản lý và giám sát tất cả các đối tượng này để mỗi người dùng có được các quyền được cấp bởi các vai trò có thể có quyền truy cập vào dữ liệu thực sự được yêu cầu để giải quyết các công việc. Cần phải sử dụng quyền truy cập làm quy tắc cho tường lửa. Sử dụng các quyền này, bạn có thể giải quyết cùng một vấn đề - để cho phép người dùng chỉ thực hiện một số tác vụ nhất định và ngăn ngừa mất mát hoặc hỏng hóc có thể xảy ra.
Với sự trợ giúp của các vai trò, việc kiểm soát quyền truy cập, cung cấp quyền hoặc chặn toàn bộ nhóm người dùng khá thuận tiện. Một vai trò có thể được bao gồm vào vai trò kia, do đó, kế thừa các quyền truy cập của nó. Do đó, chúng tôi có thể tạo cấu trúc phân cấp quyền.
Tất cả các nhân viên có quyền truy cập vào cơ sở dữ liệu của công ty có thể được gộp vào một vai trò duy nhất với các quyền tối thiểu. Bây giờ, nếu bạn cần thêm đặc quyền, quyền truy cập vào các bảng cụ thể, bạn sẽ cần thêm người dùng vào các vai trò khác (nếu một nhóm yêu cầu cùng một quyền truy cập) hoặc cung cấp một tài khoản cụ thể có quyền.
Trong chương trình, để kiểm soát quyền truy cập vào các bảng, có thể kiểm tra kết quả để tìm lỗi sau mỗi lần mở tập dữ liệu. Nếu xảy ra lỗi truy cập, quyền truy cập vào bảng được chỉ định sẽ bị chặn đối với người dùng. Do đó, không cần thực hiện các quyền truy cập vào ứng dụng khách. Tuy nhiên, nếu bạn muốn thực hiện điều này, sẽ không có hại gì. Ít nhất, tôi không thấy bất cứ điều gì quan trọng trong việc này; nó dường như có tác dụng ngược lại.
Kiểm tra bảo mật
Nếu mỗi người dùng đang làm việc với tài khoản riêng của họ trong cơ sở dữ liệu của bạn, bạn có thể gọi biến người dùng để xác định người dùng hiện tại, ví dụ:
SELECT user from dual
Truy vấn này sẽ trả về tên người dùng, theo đó kết nối với máy chủ được mở. Nếu nhiều người có thể đăng nhập bằng một tên, truy vấn này sẽ trả về cùng một tên cho cả hai và sẽ vô ích cho việc kiểm tra. Đặc biệt, nếu kiểm soát khóa xảy ra ở cấp máy chủ.
Nếu nhiều người dùng có thể đăng nhập bằng cùng một tên người dùng, thì việc xác định ai đã đăng nhập vào tài khoản sẽ rất phức tạp nhưng vẫn có thể thực hiện được. Truy vấn sau cho phép nhận thông tin chi tiết về phiên:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Như bạn có thể thấy, truy vấn trả về tên người dùng, được kết nối với cơ sở dữ liệu, tên trong hệ điều hành, tên người dùng đầu cuối và một chương trình.
Tại đây, bạn có thể truy cập dạng xem phiên v_ $ từ lược đồ hệ thống sys. Dạng xem này trả về một số thông tin về các kết nối đến máy chủ. Trong mệnh đề WHERE, chúng tôi giới hạn đầu ra chỉ cho người dùng hiện tại. Kết quả là, truy vấn trả về ID người dùng, tên, tên trong hệ điều hành, thiết bị đầu cuối và chương trình mà từ đó kết nối được thiết lập.
Khi bạn biết tên người dùng và tên thiết bị đầu cuối, bạn có thể xác định chắc chắn một người dùng. Để biết người dùng hiện tại đã được thêm vào những vai trò nào, bạn có thể chạy truy vấn sau:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Bảo mật tài khoản
Chúng tôi sẽ không nói rằng không nên có mật khẩu mặc định. Một số cơ sở dữ liệu, ví dụ, MySQL làm sai khi họ tạo một mật khẩu hệ thống đơn giản và nổi tiếng sau khi cài đặt. Chúng tôi cũng sẽ không nói rằng mật khẩu phải phức tạp. Quy tắc này áp dụng cho tất cả các lĩnh vực CNTT và ngay cả người dùng mới làm quen cũng phải biết. Chúng ta sẽ nói về các vấn đề cơ sở dữ liệu.
Theo kinh nghiệm của tôi, khi phát triển các chương trình của công ty, các nhà phát triển sử dụng cùng một tài khoản để truy cập cơ sở dữ liệu. Các tham số của tài khoản này được đăng ký trực tiếp trong chương trình, trong khi quyền truy cập vào các phân hệ cụ thể, bao gồm kế toán, kho hàng, bộ phận nhân sự, v.v. được thực hiện theo cách lập trình. Một mặt, phương pháp này thuận tiện, vì chương trình có thể kết nối với cơ sở dữ liệu với quyền quản trị viên và sẽ không phải chăm sóc các vai trò và quyền truy cập vào các bảng. Mặt khác, phương pháp này không an toàn. Mức độ người dùng đang tăng lên và bạn bè của nhân viên trong công ty của bạn có thể được đào tạo về lĩnh vực bảo mật và hack. Sau khi biết tên và mật khẩu, theo đó chương trình kết nối với cơ sở dữ liệu, một người dùng bình thường có thể nhận được nhiều cơ hội hơn bạn muốn.
Ngôn ngữ SQL không phải là một ngôn ngữ bí mật và phức tạp. Có rất nhiều chương trình sử dụng mà bạn có thể dễ dàng xem bất kỳ dữ liệu nào trong cơ sở dữ liệu. Với tên người dùng và mật khẩu, bất kỳ ai cũng có thể lấy cắp tất cả dữ liệu của bạn. Do đó, nó sẽ được bán ở bất kỳ quầy hàng nào có bán đĩa.
Tên người dùng và mật khẩu không bao giờ được lưu trữ trong chương trình. Quyền truy cập vào chương trình cũng phải được giới hạn và không thể đối với các bên thứ ba. Khá hợp lý khi kết hợp cả hai thông tin đăng nhập thành một. Cần tạo một tài khoản riêng trên máy chủ cơ sở dữ liệu với các quyền cần thiết tối thiểu cho mỗi người dùng trong tổ chức. Những tên và mật khẩu này nên được sử dụng khi đăng nhập vào chương trình. Bạn có thể sử dụng một logic phổ biến và rất hiệu quả - nếu bạn có thể đăng nhập vào cơ sở dữ liệu với dữ liệu đã nhập, quyền truy cập được cho phép; nếu không, bạn phải hủy bỏ chương trình. Quá trình này đơn giản và hiệu quả vì chúng tôi đã sử dụng ủy quyền cơ sở dữ liệu.
Để kiểm tra xem người dùng không làm việc đồng thời từ hai máy tính khác nhau có cùng tên hay không, bạn có thể thực hiện truy vấn sau:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Trên thực tế, nó không được trả về bất kỳ bản ghi nào.
Lượt xem
Chế độ xem là một cách rất thuận tiện để tắt khỏi cấu trúc dữ liệu và đồng thời xây dựng một cấp bảo vệ bổ sung. Điều đó đúng là các quan điểm có tác động tiêu cực đến năng suất, tuy nhiên, chúng có tác động tích cực đến an ninh. Chúng tôi có thể cấp quyền truy cập của riêng họ, trong khi các bảng mà dữ liệu được truy xuất từ đó vẫn không thể truy cập được vào tài khoản này.
Khi nào thì tốt hơn để sử dụng các khung nhìn? Đầu tiên, chúng ta hãy xác định nhược điểm của chúng là gì. Một khung nhìn là một câu lệnh SELECT để truy xuất dữ liệu. Nó có thể truy cập cả hai, một và một số bảng. Nếu bạn chỉ chọn dữ liệu từ chế độ xem, sẽ không bị mất hiệu suất. Tuy nhiên, chúng ta có thể sử dụng các dạng xem trong các truy vấn khác để chọn dữ liệu và tham chiếu chúng như các bảng. Ví dụ:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
Trong trường hợp này, truy vấn tìm nạp dữ liệu từ dạng xem và hai bảng. Ngoài ra, chúng ta có thể xem mối quan hệ giữa tất cả các đối tượng và một điều kiện bổ sung có thể được đặt.
Bây giờ, hãy xem truy vấn khi trình tối ưu hóa cơ sở dữ liệu nhìn thấy nó:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
Trong trường hợp này, tôi đã thay thế dạng xem bằng một câu lệnh SELECT trừu tượng trong dấu ngoặc đơn mà dạng xem bao gồm. Nó chỉ ra rằng máy chủ nhìn thấy một truy vấn với một truy vấn con. Nếu truy vấn con trả về dữ liệu động, thay vì một giá trị tĩnh, thì lựa chọn dữ liệu này sẽ hoạt động chậm hơn so với khi chúng ta viết cùng một truy vấn mà không có truy vấn con.
Bảo mật dữ liệu
Bạn không bao giờ nên cấp toàn quyền truy cập vào các đối tượng mà không có nhu cầu đặc biệt. Tôi luôn bắt đầu chỉ cung cấp quyền cho phép lựa chọn dữ liệu với câu lệnh SELECT. Nếu người dùng thực sự cần chèn các bản ghi mới và họ không thể thực hiện các tác vụ được giao, trong trường hợp này, hãy thêm quyền vào câu lệnh INSERT của bảng được chỉ định.
Các hoạt động nguy hiểm nhất đối với dữ liệu là sửa đổi và xóa, tương ứng là CẬP NHẬT và XÓA. Bạn cần phải cấp các quyền này một cách cẩn thận. Đảm bảo rằng dữ liệu có thể được sửa đổi hoặc xóa. Chỉ trong trường hợp này, hãy chọn các quyền thích hợp. Một số bảng chỉ được mở rộng theo bản chất.
Cần phải chắc chắn rằng dữ liệu sẽ bị ảnh hưởng thường xuyên. Ví dụ, bảng nhân viên có thể được mở rộng và sửa đổi, nhưng không bao giờ được xóa một bản ghi duy nhất. Việc loại bỏ có thể ảnh hưởng đến nền tảng công việc, báo cáo và tính toàn vẹn của dữ liệu của nhân viên. Trường hợp nhân viên phòng nhân sự vô tình ghi thừa và muốn xóa vẫn có thể thực hiện được. Tuy nhiên, những trường hợp như vậy rất hiếm và lỗi có thể được khắc phục bởi quản trị viên cơ sở dữ liệu. Chúng tôi hiểu rằng không ai muốn làm việc quá sức và việc cấp quyền sẽ dễ dàng hơn, tuy nhiên, tính bảo mật có giá trị hơn.
Việc cấp quyền được thực hiện bằng toán tử GRANT. Nói chung, nó trông như thế này:
CẤP quyền gì để cấp quyền cho các đối tượng BẬT CHO người dùng hoặc vai trò
Ví dụ:truy vấn sau cấp quyền chèn và xem bảng TestTable cho Người dùng1:
GRANT Select, Insert ON TestTable TO User1
Phím ngoại
Nhiều người dùng sợ các khóa ngoại vì thông thường, chúng không cho phép xóa dữ liệu khi có kết nối bên ngoài. Vấn đề có thể được giải quyết dễ dàng nếu thiết lập xóa tầng. Tuy nhiên, hầu hết các chuyên gia không thích khả năng này. Một hành động vô lý có thể làm hỏng dữ liệu rất quan trọng mà không cần bất kỳ yêu cầu xác nhận nào. Dữ liệu được liên kết phải được xóa một cách rõ ràng và chỉ khi người dùng đã xác nhận một cách có ý thức rằng dữ liệu đó mới có thể bị xóa.
Đừng sợ khóa ngoại. Chúng cung cấp cho chúng tôi một cách thuận tiện để kiểm soát tính toàn vẹn của dữ liệu từ máy chủ cơ sở dữ liệu, do đó, đây là bảo mật không bao giờ có hại. Thực tế là có thể có vấn đề với việc xóa chỉ là một lợi ích. Tốt hơn là không nên xóa dữ liệu còn hơn là để mất nó mãi mãi. Khoá ngoại cùng với chỉ mục không làm giảm hiệu suất. Đây chỉ là một kiểm tra nhỏ khi xóa dữ liệu hoặc sửa đổi trường khóa mà dữ liệu được kết nối trong các bảng khác nhau.
Sao lưu
Sao lưu cũng là một trong những yếu tố bảo mật mà chúng ta bỏ qua trước khi mất dữ liệu đầu tiên. Tuy nhiên, về mặt cá nhân, tôi sẽ đưa nó vào những cái chính. Việc mất dữ liệu có thể không chỉ do tin tặc và người dùng không thích hợp gây ra mà còn do trục trặc thiết bị. Các lỗi trong thiết bị có thể dẫn đến mất cơ sở dữ liệu, việc khôi phục có thể mất hàng giờ hoặc thậm chí vài ngày.
Cần xây dựng trước chính sách sao lưu hiệu quả nhất. Do đó có nghĩa là gì? Thời gian ngừng hoạt động do mất dữ liệu và cho đến thời điểm khôi phục khả năng làm việc phải ở mức tối thiểu. Việc mất dữ liệu cũng phải ở mức tối thiểu và việc sao lưu không được ảnh hưởng đến công việc của người dùng. Nếu có tiền và cơ hội, tốt hơn nên sử dụng các hệ thống như RAID, cụm hoặc thậm chí sao chép dữ liệu.
Sao lưu và phục hồi là một chủ đề riêng biệt và thú vị. Chúng tôi không thể chạm vào nó ở đây, nhưng chúng tôi sẽ không xem xét nó một cách chi tiết.
Tóm tắt
Chúng tôi đã xem xét các vấn đề cơ bản về bảo mật, đặc biệt là đối với Oracle. Đừng quên rằng bảo vệ được cung cấp bởi cơ sở dữ liệu chỉ là một cấp, trong khi bảo vệ phải là đa cấp. Để ngủ một chút với đầu óc tỉnh táo, cần phải triển khai toàn bộ tính năng bảo mật trên mạng, máy chủ và tất cả các máy tính, bao gồm antivirus, anti-spyware, VPN, IDS, v.v. Càng có nhiều cấp độ bảo vệ thì càng rất khó để vượt qua chúng.
Cần có một chính sách bảo mật và kiểm soát rõ ràng. Nếu một nhân viên nghỉ việc, tài khoản của họ sẽ bị xóa. Nếu bạn có người dùng làm việc với cùng một mật khẩu hoặc sử dụng mật khẩu nhóm để thực hiện bất kỳ tác vụ nào, thì tất cả các mật khẩu này phải được thay đổi. Ví dụ:nếu một quản trị viên rời đi và bạn có tất cả các quản trị viên sử dụng cùng một tài khoản, bạn phải thay đổi mật khẩu.
Bảo mật là cần thiết. Bạn không chỉ phải bảo vệ mình khỏi tin tặc mà còn khỏi những người dùng “mới bắt đầu”, những người có thể làm hỏng dữ liệu do thiếu kinh nghiệm của họ. Một chính sách bảo mật tốt giúp ngăn ngừa những trường hợp như vậy và không thể loại trừ khả năng này. Tốt hơn là bạn nên cung cấp trước khả năng bảo mật dữ liệu từ những người thiếu kinh nghiệm hơn là mất nhiều thời gian để khôi phục dữ liệu và nhận được thời gian ngừng hoạt động không cần thiết.
Cũng đọc:
Đặt quyền truy cập cơ sở dữ liệu
