An toàn và toàn vẹn dữ liệu – Bảo mật – Backup

 

    1. (60 phút) Phần A — Quyền truy cập & RBAC (Access Control)
    2. (90 phút) Phần B — Audit, logging và DDL tracking
    3. (90 phút) Phần C — Mã hóa & bảo vệ dữ liệu + Backup security
    4. (60 phút) Phần D — Giám sát, cảnh báo, phản ứng sự cố (Monitoring & Incident Response)
    5. (30 phút) Tổng kết, quiz, Q&A

Mục tiêu

Sau 6 giờ học bạn sẽ:

  1. Thiết kế và quản lý quyền người dùng theo nguyên tắc least-privilege (RBAC).
  2. Thiết lập cơ chế audit & logging hữu dụng (trigger + general log + audit tables).
  3. Triển khai mã hóa dữ liệu ở mức trường và bảo vệ backup.
  4. Tạo job / event để giám sát bất thường (dung lượng, login fail, slow query) và phản ứng (alert).
  5. Soạn quy trình xử lý sự cố (playbook) cho các tình huống an ninh phổ biến.

Chuẩn bị môi trường & tài liệu cần thiết

  • MySQL 8.0+ (InnoDB) với quyền CREATE, EVENT, TRIGGER, PROCEDURE.
  • CSDL ADMIN_DB đã tạo (bảng như đã thảo trước). Nếu chưa, dùng script khởi tạo bạn có.
  • Quyền admin để bật event_scheduler.
  • Công cụ truy cập: MySQL Workbench / mysql CLI.
  • Quyền ghi file nếu cần xuất/import.

PHẦN A — QUYỀN TRUY CẬP & RBAC (60 phút)

Mục tiêu: Hiểu cách quản lý user/role/privilege, triển khai RBAC, audit thay đổi quyền.

1. Lý thuyết nhanh (15 phút)

  • Nguyên tắc: Least Privilege, separation of duties, principle of accountability.
  • Các mức phân quyền: hệ thống (GRANT OPTION), schema, table, column, routine.
  • RBAC: Role → gán cho user; role có thể có nhiều privilege.

2. Demo & ví dụ (15 phút)

Tạo role + user + gán quyền (MySQL 8 syntax):

-- (phải chạy bởi user có quyền)
CREATE ROLE 'dba_readonly';
GRANT SELECT ON sales_db.* TO 'dba_readonly';

CREATE USER 'alice'@'%' IDENTIFIED BY 'StrongP@ssw0rd';
GRANT 'dba_readonly' TO 'alice'@'%';
SET DEFAULT ROLE 'dba_readonly' TO 'alice'@'%';

Quan sát quyền:

SHOW GRANTS FOR 'alice'@'%';

3. Lab 1 (30 phút) — Thiết lập RBAC cho ADMIN_DB

Mục tiêu lab: Tạo role admin_ops, monitor, auditor và users, gán quyền theo nguyên tắc least-privilege.
Bước thực hiện (từng bước):

  1. Tạo role:
    CREATE ROLE 'admin_ops', 'monitor', 'auditor';
    
  2. Gán quyền:
    GRANT SELECT, INSERT, UPDATE, DELETE ON ADMIN_DB.* TO 'admin_ops';
    GRANT SELECT ON ADMIN_DB.* TO 'monitor';
    GRANT SELECT ON ADMIN_DB.user_audit_log TO 'auditor';
    
  3. Tạo user và gán role:
    CREATE USER 'ops'@'localhost' IDENTIFIED BY 'OpsP@ss1';
    GRANT 'admin_ops' TO 'ops'@'localhost';
    SET DEFAULT ROLE 'admin_ops' TO 'ops'@'localhost';
    
  4. Kiểm tra: SHOW GRANTS FOR 'ops'@'localhost';

Yêu cầu đánh giá:

  • User ops có quyền ghi job_log nhưng auditor chỉ có quyền đọc user_audit_log.

PHẦN B — AUDIT & LOGGING (90 phút)

Mục tiêu: Thiết lập audit cơ bản (triggers + audit tables), cấu hình general_log/slow_query, lưu trữ và duy trì log.

1. Lý thuyết (15 phút)

  • Mục tiêu audit: truy vết hành động quan trọng (GRANT, DDL, backup, thay đổi quyền).
  • Nguồn audit: triggers (bảng nội bộ), general_log, slow_query_log, binary log (forensic), hệ thống audit plugin (Enterprise).
  • Quy tắc: audit không được làm hệ thống chậm, nên dùng summary hoặc sample, phân vùng lưu trữ log.

2. Demo: Tạo trigger audit cho user_privileges (20 phút)

Tạo bảng audit (nếu chưa có):

CREATE TABLE IF NOT EXISTS user_audit_log (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  actor VARCHAR(100),
  action_type VARCHAR(50),
  object_name VARCHAR(100),
  details TEXT,
  event_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

Trigger AFTER INSERT/UPDATE/DELETE:

DELIMITER $$
CREATE TRIGGER trg_user_priv_after_insert
AFTER INSERT ON user_privileges
FOR EACH ROW
BEGIN
  INSERT INTO user_audit_log (actor, action_type, object_name, details)
  VALUES (CURRENT_USER(), 'GRANT', NEW.db_name, CONCAT('priv=', NEW.privilege_type));
END$$
DELIMITER ;

(Lặp lại tương tự cho UPDATE/DELETE)

Kiểm thử:

  • Thực hiện INSERT INTO user_privileges ...SELECT * FROM user_audit_log;

3. Lab 2 (55 phút) — Thiết lập audit & retention

Mục tiêu lab:

  • Thiết lập triggers audit cho user_accounts, tbl_tables, backup_log.
  • Tạo job/event để purge log cũ > 90 ngày.

Các bước:

  1. Tạo audit table chung admin_audit_log (nếu muốn tập trung):
    CREATE TABLE admin_audit_log (
      id BIGINT AUTO_INCREMENT PRIMARY KEY,
      module VARCHAR(50),
      actor VARCHAR(100),
      action_type VARCHAR(50),
      object_name VARCHAR(100),
      details TEXT,
      event_time DATETIME DEFAULT CURRENT_TIMESTAMP
    ) ENGINE=InnoDB;
    
  2. Viết triggers (ví dụ cho backup_log):
    DELIMITER $$
    CREATE TRIGGER trg_backup_after_insert
    AFTER INSERT ON backup_log
    FOR EACH ROW
    BEGIN
      INSERT INTO admin_audit_log (module, actor, action_type, object_name, details)
      VALUES ('BACKUP', CURRENT_USER(), NEW.status, NEW.db_name, NEW.file_path);
    END$$
    DELIMITER ;
    
  3. Tạo event xóa log cũ:
    SET GLOBAL event_scheduler = ON;
    CREATE EVENT ev_purge_audit
    ON SCHEDULE EVERY 1 DAY
    DO
      DELETE FROM admin_audit_log WHERE event_time < NOW() - INTERVAL 90 DAY;
    
  4. Kiểm thử: chèn sample, chạy event (or wait), kiểm tra xóa.

Yêu cầu: Audit ghi đủ thông tin: actor, action, object, time. Event purge hoạt động.

PHẦN C — MÃ HÓA & BẢO VỆ BACKUP (90 phút)

Mục tiêu: Áp dụng mã hóa ở mức trường (field-level), bảo vệ file backup và thảo luận về TDE/SSL.

1. Lý thuyết (20 phút)

  • Mã hóa at-rest vs in-transit vs field-level.
  • MySQL: dùng AES_ENCRYPT()/AES_DECRYPT() cho cột, dùng SSL cho kết nối, TDE (Transparent Data Encryption) thường là tính năng Enterprise — nếu không có, encrypt backup files externally (gpg/openssl).
  • Backup security: bảo vệ file, checksum, offsite copy, rotation, access control.

2. Demo: Mã hóa field với AES (20 phút)

Tạo cột lưu secret (ví dụ file_path encrypted):

ALTER TABLE backup_log ADD COLUMN file_path_enc VARBINARY(512);

-- Mã hóa khi insert (ví dụ key tạm)
SET @k = SHA2('MyVeryStrongKey123!',512);

INSERT INTO backup_log (db_name, backup_type, backup_size_mb, duration_sec, status, file_path_enc)
VALUES ('sales_db','FULL',512.5,120,'SUCCESS', AES_ENCRYPT('/backups/sales_2025-10-01.bak', @k));

Giải mã khi cần:

SELECT db_name, AES_DECRYPT(file_path_enc, @k) AS file_path
FROM backup_log WHERE id = 1;

Ghi chú:

  • Không lưu key trong DB plain text; key nên quản lý ngoại vi (KMS) hoặc biến môi trường.

3. Demo: Bảo vệ backup file (quy trình, không code hệ thống)

Quy trình an toàn backup:

  1. Dump DB hoặc dùng công cụ backup.
  2. Mã hóa file backup bằng gpg hoặc openssl:
    • openssl enc -aes-256-cbc -salt -in dump.sql -out dump.sql.enc -kfile /secure/km/keyfile
  3. Tạo checksum:
    • sha256sum dump.sql.enc > dump.sql.enc.sha256
  4. Lưu trữ offsite, kiểm tra restore test định kỳ.

4. Lab 3 (50 phút) — Mã hóa cột + backup secure

Mục tiêu:

  • Thực hiện mã hóa cột file_path trong backup_log.
  • Viết stored procedure sp_add_backup dùng AES_ENCRYPT và lưu metadata; stored proc phải xử lý key từ biến input (mô phỏng KMS).
  • Mô phỏng mã hóa file backup bằng lệnh shell (mô tả, thực hành nếu có quyền server).

Bước thực hiện (SQL):

DELIMITER $$
CREATE PROCEDURE sp_add_backup(IN p_db VARCHAR(100), IN p_path TEXT, IN p_key VARCHAR(255))
BEGIN
  DECLARE v_enc VARBINARY(512);
  SET v_enc = AES_ENCRYPT(p_path, SHA2(p_key,512));
  INSERT INTO backup_log (db_name, backup_type, file_path_enc, status, backup_size_mb, duration_sec)
  VALUES (p_db, 'FULL', v_enc, 'SUCCESS', 0, 0);
END$$
DELIMITER ;

Kiểm thử:

CALL sp_add_backup('demo_db','/secure/backups/demo.sql','MyKmsLikeKey');
SET @k = SHA2('MyKmsLikeKey',512);
SELECT AES_DECRYPT(file_path_enc,@k) FROM backup_log WHERE db_name='demo_db' ORDER BY id DESC LIMIT 1;

Ghi chú an toàn: Key không được commit vào source control.

PHẦN D — GIÁM SÁT, CẢNH BÁO & PHẢN ỨNG SỰ CỐ (60 phút)

Mục tiêu: Tự động phát hiện bất thường (dung lượng, login fail, slow query) và định nghĩa playbook đơn giản xử lý sự cố.

1. Lý thuyết (10 phút)

  • Metrics cần giám sát: growth (size), slow queries, failed logins, high I/O, unusual grants.
  • Cơ chế: Event Scheduler + stored procedures + alert_log table + notification (email/webhook).

2. Demo: Event giám sát dung lượng + tạo alert (15 phút)

Stored proc log sizes (như đã làm):

CREATE PROCEDURE sp_log_db_size()
BEGIN
  INSERT INTO space_usage (db_name, data_size_mb, index_size_mb, total_size_mb)
  SELECT table_schema,
         ROUND(SUM(data_length)/1024/1024,2),
         ROUND(SUM(index_length)/1024/1024,2),
         ROUND(SUM(data_length+index_length)/1024/1024,2)
  FROM information_schema.tables
  WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys','ADMIN_DB')
  GROUP BY table_schema;
END;

Event hàng ngày:

SET GLOBAL event_scheduler = ON;
CREATE EVENT IF NOT EXISTS ev_daily_dbsize
ON SCHEDULE EVERY 1 DAY
DO CALL sp_log_db_size();

Proc detect growth anomaly (ví dụ > 20% so với 7 ngày trước):

CREATE PROCEDURE sp_detect_growth_anomaly()
BEGIN
  INSERT INTO alert_log (alert_type,severity,message)
  SELECT 'GROWTH_ANOMALY','HIGH', CONCAT('DB ', db_name, ' tăng >20% so với 7 ngày trước.')
  FROM (
    SELECT db_name,
           MAX(total_size_mb) AS now_mb,
           SUBSTRING_INDEX(GROUP_CONCAT(total_size_mb ORDER BY recorded_at SEPARATOR ','), ',', 2) as earlier_vals
    FROM space_usage
    GROUP BY db_name
  ) t
  WHERE /* dùng logic phù hợp để so sánh */ false;
END;

(Ở lab bạn sẽ triển khai so sánh thực tế dựa trên 2 snapshot cụ thể.)

3. Lab 4 (35 phút) — Giám sát & Playbook xử lý cảnh báo

Mục tiêu:

  • Tạo event ev_check_quota chạy hourly và gọi sp_check_quota() để so sánh space_usage cuối cùng với quota_threshold và insert alert.
  • Soạn playbook xử lý alert CAPACITY_EXCEEDED (bước bằng văn bản và SQL).

Bước thực hiện (các đoạn SQL mẫu):

-- Stored procedure
DELIMITER $$
CREATE PROCEDURE sp_check_quota()
BEGIN
  INSERT INTO alert_log (alert_type,severity,message,db_name)
  SELECT 'CAPACITY_EXCEEDED','CRITICAL',
         CONCAT('DB ', s.db_name, ' size ', s.total_size_mb, 'MB > threshold ', q.threshold_mb, 'MB'),
         s.db_name
  FROM (SELECT db_name, total_size_mb FROM space_usage WHERE recorded_at = (SELECT MAX(recorded_at) FROM space_usage)) s
  JOIN quota_threshold q ON s.db_name = q.db_name
  WHERE s.total_size_mb > q.threshold_mb;
END$$
DELIMITER ;

-- Event hourly
CREATE EVENT IF NOT EXISTS ev_check_quota
ON SCHEDULE EVERY 1 HOUR
DO CALL sp_check_quota();

Playbook xử lý alert (văn bản + SQL):

  1. Nhận cảnh báo: alert_log with status OPEN.
  2. Xác minh: kiểm tra top tables growth:
    SELECT table_name, ROUND((data_length+index_length)/1024/1024,2) AS size_mb
    FROM information_schema.tables
    WHERE table_schema = 'problem_db'
    ORDER BY size_mb DESC LIMIT 10;
    
  3. Biện pháp tạm thời: disable job causing huge writes, hoặc tăng retention.
  4. Lâu dài: phối hợp dev fix logic app, tạo archival script.
  5. Ghi lại resolution: cập nhật alert_log.status = 'RESOLVED', add notes.

KẾT THÚC & KIỂM TRA (30 phút)

  • Quiz ngắn (10 phút): 10 câu trắc nghiệm / thực hành nhanh (ví dụ: viết 1 câu lệnh revoke, viết trigger đơn giản).
  • Thực hành kiểm tra (15 phút): cho 1 scenario nhỏ (DB tăng đột biến) — học viên phải dùng query detect và tạo alert demo.
  • Q&A (5 phút)

Tài liệu & mẫu mã (đính kèm trong bài giảng)

  • Tất cả đoạn SQL mẫu đã xuất trong từng lab.
  • Mẫu file playbook xử lý alert (Markdown).
  • Checklist bảo mật mà DBA cần duy trì (user review monthly, backup test quarterly, key rotation policy).

Bổ sung: Checklist triển khai an ninh cho DBA (tóm tắt, có thể in)

  1. Quản lý user/role:
    • Review user list & privileges hàng tháng.
    • Không sử dụng shared accounts; audit every privileged account.
  2. Audit & logging:
    • Bật audit triggers cho critical tables.
    • Rotate logs & purge > retention.
    • Lưu log offsite nếu cần compliance.
  3. Encryption & key management:
    • Không lưu key trong mã nguồn. Sử dụng KMS.
    • Mã hóa backups & truyền tải (SSL).
  4. Backup & restore:
    • Lên lịch backup, checksum, test restore quarterly.
    • Document RTO/RPO.
  5. Monitoring & alerts:
    • Giám sát growth, failed logins, slow queries.
    • Tự động alert via email/webhook.
  6. Change control:
    • Mọi DDL qua change request; ghi log.
    • Migration chỉ trên staging trước production.

Tùy chọn mở rộng (sau khóa)

  • Tích hợp ADMIN_DB với Prometheus + Grafana để visual dashboard.
  • Thiết lập email/webhook notification (ví dụ dùng UDF hoặc script bên ngoài).
  • Sử dụng vault/KMS (HashiCorp Vault / AWS KMS) để quản lý key.

 

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *