Mục đích: Bộ tiêu chuẩn cài đặt, vận hành, giám sát, kiểm soát truy cập của Oracle Database, MySQL/MariaDB, PostgreSQL, SQL Server
1. Bộ tiêu chuẩn cài đặt Oracle Database
Tiêu chuẩn | Yêu cầu |
MÔ HÌNH |
|
Mô hình kết nối | - Oracle RAC (Active – Active) - Oracle Active – Standby dùng DataGuard hoặc GoldenGate |
Mô hình dự phòng | Các nghiệp vụ quan trọng, online thì phải có thêm mức dự phòng với công nghệ Oracle DataGuard (nếu cùng nền tảng) hoặc Oracle GoldenGate (nếu khác nền tảng) và phòng ngừa thảm họa (DR) với 1 trong 2 công nghệ trên. |
CẤU HÌNH CÀI ĐẶT |
|
Vesion | Cài đặt phiên bản mới nhất hoặc gần phiên bản mới nhất 1 phiên bản (Ví dụ Oracle Database mới nhất là 19.16 thì có thể cài đặt 19.15). (Phiên bản mới nhất sẽ patch mọi lỗ hổng của phiên bản trước đó nhưng độ ổn định thì không bằng phiên bản phiên bản mới nhất -1 được) |
Patch | Patch đầy đủ theo phiên bản cài đặt |
Control file | Tối thiểu 02 control file trên 02 phân vùng (mount point hoặc diskgroup) khác nhau |
Redo Log Group | Có ít nhất 3 redo log group mỗi instance DB, mỗi redo log group có ít nhất 2 member trên 2 vùng khác nhau, đảm bảo mirror dự phòng cho nhau. |
Database ở chế độ archived log | Database chạy ở chế độ archive log mode |
Tablespace | Tablespace UNDO, TEMP, ứng dụng có các datafile nằm trên ít nhất 02 datafile trên 2 mount point khác nhau (nếu dạng file system) và ít nhất 02 datafile (nếu là ASM) |
Bộ nhớ SGA, PGA | Dung lượng SGA + PGA tương đương 80% dung lượng RAM (trong đó nghiệp vụ OLTP thì SGA cấp 80%, PGA cấp 20%; với nghiệp vụ DSS thì SGA cấp tối thiểu 30%, PGA tối đa 70%) |
Tham số db_files | DB_FILES khai báo từ 1000 – 10000. |
Tham số resource_limit | Đặt tham số resource_limit = true để các chính sách user profile đặt trong DB có hiệu lực. |
Tham số process | Đặt các tham số sessions, proceses (500-5000) phù hợp với yêu cầu nghiệp vụ của từng DB. |
Chế độ dedacated server | DB chạy chế độ Dedacated server Nếu tài nguyên hữu hạn có thể đặt chế độ shared server (shared_server từ 50 – 400), các ứng dụng kết nối vào cũng đang chạy theo chế độ shared. |
Cấu hình backup | Cấu hình RMAN giữ ít nhất 2 bản full và đảm bảo các điều kiện sau:
Nên đặt db_block_checking |
Yêu cầu ASM diskgroup, ASM disk | Đối với DB sử dụng ASM: · Có ít nhất 3 disk group khác nhau (CRS, DATA, RECO) · Mỗi disk group có ít nhất 4 LUN cùng size dạng external, nếu diskgroup lưu dữ liệu quan trọng nên dùng normal (CRS là bắt buộc phải dùng kiểu normal với tối thiểu 3 disk) |
Thiết lập HugePage | DB có RAM 8GB cần thiết lập HugePage tối thiểu 2MB (vì mặc định page memory là 4K) |
Audit_db | Đặt audit_db=none để tránh ảnh hưởng đến tải DB |
2. Bộ tiêu chuẩn thiết kế database
Tiêu chuẩn | Yêu cầu |
Tiêu chuẩn chung của các objects | · Các object đặt option noparallel. · Drop các user không sử dụng, revoke quyền DBA của các user. · Kiểm tra profile chứa user ứng dụng đảm bảo profile này đặt unlimited cho mọi tham số. · Bảng dữ liệu ứng dụng không nằm trên tablespace mặc định là USERS · Không xuất hiện corrupt block trong DB. · Tất cả các object ở trạng thái valid (các object bị invalid thì phải drop). · Tất cả index không ở trạng thái unusable. · Định dạng tên partition đối với các bảng đánh partition theo thời gian là DATAyyyy, DATAyyyymm hay DATAyyyymmdd tuỳ theo loại partition (partition theo năm, tháng hoặc ngày tương ứng) |
Cấu trúc bảng | Khi tạo bảng mới cần áp dụng các phương án như sau: · Với bảng có dữ liệu dự kiến lớn, có tính lịch sử (như bảng log giao dịch) phải đánh partition:
· Với các bảng có đánh partition thì index phải đánh theo Local. · Hạn chế sử dụng trigger trên bảng. · Đánh giá trong câu lệnh select có trường nào xác định được đối tượng tìm kiếm chính xác nhất và có độ dài trường ngắn nhất (ưu tiên trường number) thì đánh index theo trường đó. · Hạn chế dùng foreign key, nếu dùng thì trường foreign key của bảng con đó phải đánh index. · Với các bảng có tần suất update hoặc insert lớn không nên dùng primary key/unique key |
Câu lệnh SQL nghiệp vụ | Khi viết câu lệnh tác động vào bảng cần làm theo hướng dẫn sau: · Tất cả các câu lệnh đều phải có index, không câu lệnh nào được quét full bảng (với hệ thống Report/DSS khi quét full cần thêm hint parallel) · Nếu bảng có partition thì trong câu lệnh phải có thêm trường partition (ngoại trừ một số trường hợp đặc biệt). · Khi join hai bảng với nhau thì bảng có dữ liệu lớn hơn phải có index. · Trong câu lệnh không dùng điều kiện is null, cần chuyển sang phương án dùng các toán tử : >, <, =. · Hạn chế sử dụng câu lệnh delete, cần chuyển sang câu lệnh truncate, dữ liệu cũ chuyển sang bảng mới · Hạn chế sử dụng câu lệnh update, cần chuyển sang câu lệnh insert và select. · Với các bảng tmp có dữ liệu trong quá trình chạy và xóa dữ liệu sau khi chạy (không cần backup dữ liệu), cần chuyển bảng sang nologging và câu lệnh insert cần có thêm append. |
View | Các lưu ý khi tạo view: · Trong view không nên thêm trường mới vì khi câu lệnh select vào view có thể sẽ bị quét full bảng. · Hạn chế sử dụng view lồng nhau. |
Tạo tablespace: | Với mỗi DB thường, tạo các loại tablespace như sau: · Các datafile có thể đặt auto extend để tiết kiệm dung lượng (nếu kiểm soát được), còn không thì không đặt auto extend, size 4GB, 8GB, 16GB, 32GB, 64GB. · Tablespace cố định: để lưu default các user ứng dụng, các bảng không có partition, các bảng danh mục, đặt trên là DATA, tương ứng lưu index là INDX · Tablespace không cố định: lưu các bảng có partition, ví dụ DATA202212, tương ứng là INDX202212 và DATA2022, tương ứng là INDX2022,.... · Tablespace nghiệp vụ: lưu các bảng của nghiệp vụ tạo ra, ví dụ: DATA_NGHIEPVU1, INDX_NGHIEPVU1, DATA_NGHIEPVU2, INDX_NGHIEPVU2 · Tablespace DUMP: lưu các bảng temp, test, xoá liên tục,... không cần backup tablespace này · Tablespace LOB: Lưu dữ liệu lob, nếu dữ liệu LOB lớn thì tách ra theo năm/tháng LOByyyy, LOByyyymm · Loại tablespace USERS (mặc định): Lưu dữ liệu user cá nhân hỗ trợ nghiệp vụ |
3. Bộ tiêu chuẩn vận hành database an toàn, tối ưu
Tiêu chuẩn | Yêu cầu |
Mô hình kết nối | Oracle RAC (Active – Active) hoặc Oracle Active – Standby |
Mô hình dự phòng | Các nghiệp vụ quan trọng, online thì phải có thêm mức dự phòng với công nghệ Oracle DataGuard (nếu cùng nền tảng) hoặc Oracle GoldenGate (nếu khác nền tảng) và phòng ngừa thảm họa (DR) với 1 trong 2 công nghệ trên. |
Cấu hình cảnh báo | Cấu hình cảnh báo DB như các DB khác đang chạy: · Đặt cảnh báo Tablespace · Đặt cảnh báo ASM disk group · Đặt cảnh báo disk u01, / · Đặt cảnh báo performance phù hợp với mỗi database (ví dụ DB Core > 250 active là timeout, lock > 50 là có nguy cơ timeout nghiệp vụ,…) · Đặt cảnh báo alert log · Đặt cấu hình Analyze bảng và index · Đặt trigger Firewall DB · Đặt cảnh báo tác động DDL · Đặt cảnh báo tác động DML (FGA) · Đặt cảnh báo Listener, instance, log backup … |
Cơ chế backup DB | · Giữ ít nhất 2 bản backup full gần nhất. · Đẩy sớm lên backup tập trung (đối với các DB chạy trên local disk), 1 tuần có tối thiểu 01 bản backup full lưu trữ ở storage khác với phân vùng chứa datafile. Luôn có 03 bản backup full (dùng RMAN và datapump) vào đầu năm, giữa năm và hiện tại theo chu kỳ 01 năm. · (RMAN để dựng lại cùng môi trường; còn bản datapump để ứng cứu import trên môi trường khác) |
Phương án ứng cứu khi lỗi dữ liệu 1 phần | Có thủ tục step by step khả thi hướng dẫn ứng cứu khi lỗi 1 phần DB Thủ tục này đã được thử nghiệm chưa, thời gian khôi phục hết bao lâu? |
Phương án ứng cứu khi lỗi toàn bộ DB | Có thủ tục step by step khả thi hướng dẫn ứng cứu khi lỗi toàn bộ DB Thủ tục này đã được thử nghiệm chưa, thời gian khôi phục hết bao lâu? |
Profile cho user DB | User cá nhân và user ứng dụng đặt trên 2 profile có policy khác nhau (user cá nhân đặt giới hạn 3 session, expire password 30-45 ngày; user ứng dụng đặt unlimited) |
Audit DB | Với các dữ liệu nhạy cảm cần đặt audit bằng FGA hoặc công cụ bên thứ 3 (VD Imperva, Oracle Database Firewall & Audit Vault), các bảng log audit cần phải đặt trên tablespace riêng không thuộc system tablespace (ví dụ tablespace DATA_AUDIT, INDX_AUDIT). |
Bảng lớn | Với bảng có dữ liệu lớn (2G trở lên) cần trao đổi sớm với nghiệp vụ để đánh partition. - Với dữ liệu lịch sử thì đánh theo By Range (thường theo ngay tháng) - Với dữ liệu xác định trước được giá trị thì đánh theo By list. - Với dữ liệu không có quy luật thì đánh theo By Hash. - Hoặc kết hợp các kiểu partition cho hợp lý Nguyên tắc: Chia để trị, chia nhỏ bảng lớn ra để việc quét dữ liệu ít hơn, tối ưu hơn cho câu lệnh SQL. |
Drop các bảng không sử dụng | Thường xuyên rà soát, drop các bảng không sử dụng, bảng rác: · Drop tất cả các bảng ứng dụng không sử dụng. · Drop tất cả các bảng rác do user cá nhân tạo ra. (Lưu ý backup trước khi drop; backup bằng datapump hoặc CTAS) |
Kiểm tra chính sách quay vòng dữ liệu | Xác định chính sách vòng đời của các bảng dữ liệu theo quy định. |
Giám sát cảnh báo | Liên tục giám sát cảnh báo qua SMS, Polestar, email báo cáo hàng ngày, nghiệp vụ,… và xử lý |
Tự động hóa | Bổ sung các job tự động dọn dẹp OS/DB, backup, báo cáo add datafile, partition, kill, gather… |
Cập nhật tài liệu vận hành | Bổ sung, cập nhật tài liệu vận hành khi có sự điều chỉnh phù hợp hơn hoặc khi có case lỗi phát sinh. |
Cập nhật hệ thống | Có thủ tục, phương án rõ ràng, đầy đủ, đặc biệt phải backup và phải rollback được trong trường hợp cập nhật lỗi. |
4. Bộ tiêu chuẩn giám sát, kiểm soát truy cập người dùng
Tiêu chí | Yêu cầu | ||||||||||||||||||||
Xác thực 02 yếu tố | Xác thực thêm yếu tố IP trigger Firewall DB | ||||||||||||||||||||
Giám sát database | Tuân thủ quy định giám sát database mục 3.Bộ tiêu chuẩn vận hành database | ||||||||||||||||||||
Cấp phát user mới | Khi xin tạo mới user truy cập vào database cần cung cấp thông tin: - Mô hình kết nối tổng thể của hệ thống; - Chủ trương kết nối vào database để khai thác dữ liệu (như văn bản chỉ đạo, quy trình, quy định,…); - Dự kiến tần suất truy cập vào các dữ liệu; - Tuân thủ cam kết đảm bảo an toàn thông tin | ||||||||||||||||||||
Mật khẩu | · Tối thiểu 8 ký tự, có số, chữ cái hoa thường và ký tự đặc biệt. · Các thuộc tính của mật khẩu: - Số lần login fail trước khi bị lock: 5 - Thời gian lock: 1 giờ - Thời hạn mật khẩu: o User ứng dụng: Không cần đổi mật khẩu o User thường: Đổi mật khẩu định kỳ theo quy chế ATTT (thường <=45 ngày) - Thời gian được sử dụng lại mật khẩu cũ: >= 365 ngày | ||||||||||||||||||||
Session | - Tiêu chuẩn với nhóm user thông thường: o Số lượng tối đa session được mở của user <=4 o Mật khẩu phải được thay đổi thường xuyên theo quy chế ATTT o Giới hạn active session <=4 o Giới hạn parallel <=4 o Các giới hạn khác theo nhu cầu (như RAM, undo, redo,…): Cấu hình khi cần thiết - Tiêu chuẩn với nhóm user ứng dụng: Thông thường sẽ không giới hạn để nghiệp vụ chủ động kiểm soát, trong trường hợp ứng dụng chiếm tải mà ảnh hưởng đến các nghiệp vụ khác khi dùng chung DB thì cần giới hạn tài nguyên về số số lượng session, active session, parallel, CPU và tự động kill sesion chiếm tải, inactive lớn. | ||||||||||||||||||||
Quyền truy cập | Khi xin bổ sung quyền truy cập vào database cần cung cấp thông tin: - Mô hình kết nối tổng thể của hệ thống; - Chủ trương kết nối vào database để khai thác dữ liệu (như văn bản chỉ đạo, quy trình, quy định,…); - Dự kiến tần suất truy cập vào các dữ liệu; - Tuân thủ cam kết đảm bảo an toàn thông tin. | ||||||||||||||||||||
Giám sát log tác động của user vào database
| Với các tác động vào kho tài nguyên của Doanh nghiệp (Viễn thông có thông tin khách hàng (đấu nối, chặn cắt, thay đổi thông tin, chi tiết cước, thanh toán, công nợ,…); sản phẩm (kho sim, kho số, thẻ cào, hàng hóa,..); và các bảng quan trọng khác: · User ứng dụng chính khi kết nối vào DB cần phải ghi log đầy đủ và báo cáo theo quy chế ATTT. · User của ứng dụng của các hệ thống phụ trợ khác: cần phải ghi log đầy đủ, đẩy file log về hệ thống audit tập trung của TCT và có báo cáo định kỳ hàng ngày hoặc bất thường về Trung tâm Vận hành Hạ tầng, Ban CNTT · User vận hành nghiệp vụ: cần phải ghi log đầy đủ và có báo cáo định kỳ hàng ngày hoặc bất thường về Trung tâm Vận hành Hạ tầng, Ban CNTT Ví dụ mẫu báo cáo: Bao cao truy cap CSDL xxxx
|
5. Bộ tiêu chuẩn cho các DB khác (MySQL/MariaDB, PostgreSQL, SQL Server,...):
Tiêu chuẩn | Yêu cầu |
CÀI ĐẶT |
|
Mô hình kết nối | Active-Active hoặc Active - Standnby |
Mô hình dự phòng | Có dự phòng ở site khác với DB quan trọng |
Vesion | Cài đặt phiên bản mới nhất hoặc phiên bản mới nhất -1 phiên bản |
Patch | Patch mới nhất đầy đủ, mới nhất |
THIẾT KẾ |
|
Tạo partiton của bảng lớn | Với các bảng dữ liệu lớn, có lịch sử cần tạo partition hợp lý |
Tạo index | Index local và tối thiểu hóa index |
VẬN HÀNH |
|
Giám sát DB | Liên tục giám sát cảnh báo qua Polestar hoặc TOAD,… |
Tự động hóa | Bổ sung các job tự động dọn dẹp OS/DB, backup, báo cáo |
Có vòng đời lưu trữ dữ liệu | Có vòng đời lưu trữ dữ liệu hợp lý |
Nơi lưu trữ backup dữ liệu | Backup trên SAN khác với SAN lưu datafile |
Bản backup dữ liệu | Luôn có 03 bản backup full vào đầu năm, giữa năm và hiện tại theo chu kỳ 01 năm |
Phương án ứng cứu khi lỗi dữ liệu 1 phần | Có thủ tục step by step khả thi hướng dẫn ứng cứu khi lỗi 1 phần DB |
Phương án ứng cứu khi lỗi toàn bộ DB | Có thủ tục step by step khả thi hướng dẫn ứng cứu khi lỗi toàn bộ DB |
Cập nhật tài liệu vận hành | Khi có sự thay đổi tốt hơn cần bổ sung, cập nhật tài liệu vận hành hoặc khí có các case lỗi |
Cập nhật hệ thống | Có thủ tục, phương án rõ ràng, đầy đủ, đặc biệt phải backup và phải rollback được trong trường hợp cập nhật lỗi |
Giám sát, kiểm soát truy cập người dùng | Tương tự như tiêu chuẩn ATTT với Oracle Database |
