Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và điện toán đám mây, hệ điều hành Linux — đặc biệt là bản phân phối CentOS (Community Enterprise Operating System) — đã trở thành nền tảng máy chủ cốt lõi cho hơn 60% hạ tầng doanh nghiệp IT nhờ tính ổn định cao, tương thích nhị phân với Red Hat Enterprise Linux (RHEL) và chi phí tối ưu. Tuy nhiên, theo báo cáo an ninh mạng toàn cầu, hơn 70% các vụ tấn công xâm nhập hệ thống bắt nguồn từ các lỗ hổng cấu hình sai (misconfigurations), cổng dịch vụ dư thừa và chính sách kiểm soát quyền hạn lỏng lẻo.

Thực tế tại nhiều tổ chức, quy trình thiết lập và gia cố bảo mật (server hardening) cho hệ điều hành máy chủ vẫn thực hiện thủ công từng bước qua giao diện dòng lệnh (CLI). Phương pháp này bộc lộ nhiều điểm nghẽn nghiêm trọng:

  • Tốn thời gian và nhân lực: Cấu hình thủ công chuẩn an toàn cho một máy chủ CentOS mất từ 30 đến 60 phút, gây quá tải khi mở rộng quy mô hàng trăm máy chủ.
  • Sai sót con người (Human Error): Quá trình nhập lệnh lặp đi lặp lại dễ dẫn đến thiếu sót các tham số bảo mật trọng yếu như SSH, SELinux hoặc phân quyền file hệ thống.
  • Thiếu tính nhất quán và kiểm toán: Không có cơ chế báo cáo tập trung, gây khó khăn cho việc đánh giá mức độ tuân thủ tiêu chuẩn an toàn thông tin định kỳ.

Đồ án khóa luận "Tự động hóa cấu hình và nâng cao tính bảo mật cho hệ điều hành CentOS" (Automated Configuring and Hardening CentOS) của nhóm tác giả Huỳnh Minh Thái và Phạm Nguyễn Hữu Tân (Khoa Mạng máy tính và Truyền thông, Trường Đại học Công nghệ Thông tin – ĐHQG-HCM, hướng dẫn bởi ThS. Trần Thị Dung) được xây dựng nhằm giải quyết triệt để các bài toán trên.

Mục tiêu cụ thể của dự án:

  1. Nghiên cứu và xây dựng bộ tiêu chuẩn đánh giá an toàn thông tin cho CentOS 7 dựa trên chuẩn quốc tế CIS Benchmark (Center for Internet Security).
  2. Phát triển hệ thống tự động hóa quá trình quét lỗ hổng cấu hình (Audit) và tự động khắc phục/gia cố (Remediation) dựa trên nền tảng mã nguồn mở Ansible.
  3. Tích hợp giải pháp quản trị tập trung thông qua giao diện Web trực quan (GUI) sử dụng Jenkins và Ansible AWX, kèm hệ thống cảnh báo tức thời qua Telegram.
  4. Tối ưu hóa thời gian triển khai, đảm bảo tính bất biến (idempotency) và báo cáo trực quan dưới dạng HTML/CSS.

Phương pháp tiếp cận sử dụng mô hình tự động hóa không phụ thuộc Agent (Agentless Automation) thông qua giao thức bảo mật SSH và ngôn ngữ khai báo YAML. Kết quả kỳ vọng là rút ngắn thời gian rà soát và cấu hình bảo mật trên toàn bộ hệ thống máy chủ từ hàng giờ xuống dưới 2 phút mỗi máy, bao phủ hơn 85 quy tắc kiểm soát an toàn nghiêm ngặt.

Phạm vi nghiên cứu tập trung vào hệ điều hành CentOS 7.x, áp dụng cho các hạ tầng máy chủ nội bộ (on-premise), máy chủ ảo hóa (VirtualBox, OpenVZ) và môi trường cloud VPS, với giới hạn kiểm soát ở tầng hệ điều hành và dịch vụ lõi.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi thiết kế giải pháp tự động hóa, việc phân tích các công cụ quản lý cấu hình (Configuration Management) hiện hành là bắt buộc nhằm lựa chọn nền tảng tối ưu nhất cho bài toán an toàn thông tin:

Tiêu chí Quản trị thủ công (Shell Script) Puppet / Chef SaltStack Giải pháp Ansible (Đồ án)
Kiến trúc Không có kiến trúc chuẩn Client - Server (Cần Agent) Master - Minion (Cần Agent) Agentless (Chỉ cần SSH & Python)
Độ phức tạp cài đặt Thấp nhưng khó duy trì Rất cao (Cài đặt & duy trì Agent) Trung bình Rất thấp (Cài đặt tại Control Node)
Ngôn ngữ khai báo Bash / Shell (Khó kiểm soát lỗi) Ruby / Puppet DSL Python / YAML YAML (Dễ đọc, chuẩn hóa cao)
Tính bất biến (Idempotent) Phải tự code logic kiểm tra Hỗ trợ tốt Hỗ trợ tốt Tự động hỗ trợ qua Module lõi
Tài nguyên chiếm dụng Không đáng kể Tốn RAM/CPU nền trên Target Tốn tài nguyên duy trì Minion 0% RAM/CPU ở chế độ chờ (Idle)

Dựa trên phương pháp phân loại yêu cầu MoSCoW, hệ thống xác định các tiêu chí:

  • Must have: Tự động quét và phát hiện lỗi cấu hình; tự động sửa lỗi theo chuẩn CIS; cơ chế Agentless qua SSH; xuất báo cáo HTML trực quan.
  • Should have: Giao diện điều khiển Web (AWX / Jenkins); quản lý phân quyền người dùng; hỗ trợ chạy song song (Parallel execution).
  • Could have: Tích hợp Webhook gửi thông báo kết quả build qua Telegram; lọc các rule cần hardening thông qua thẻ Tags.
  • Won't have (lần này): Tự động phát hiện mã độc thời gian thực (EDR) hoặc can thiệp sâu vào nhân Kernel thời gian thực.

Thách thức kỹ thuật lớn nhất là phải đảm bảo quá trình tự động cấu hình không làm gián đoạn các dịch vụ đang vận hành hoặc khóa quyền truy cập hợp lệ của quản trị viên (chẳng hạn cấu hình sai chính sách SSH hoặc firewall).

Thiết kế hệ thống

Kiến trúc tổng thể của hệ thống bao gồm 2 thành phần chính: Control Server và Remote Hosts (Managed Nodes) kết nối với nhau hoàn toàn thông qua giao thức SSH chuẩn (Port 22).

+-------------------------------------------------------------------------------+
|                                CONTROL SERVER                                 |
|                                                                               |
|  +---------------------+   +---------------------+   +---------------------+  |
|  |     Ansible AWX     |   |       Jenkins       |   |  Nginx Web Server   |  |
|  |  (Web GUI / Workflows)  |   |  (CI/CD Automation) |   |  (Report Host / SSL)|  |
|  +----------+----------+   +----------+----------+   +----------+----------+  |
|             |                         |                         ^             |
|             +--------------------+----+                         |             |
|                                  |                              |             |
|                     +------------v------------+                 |             |
|                     |      Ansible Engine     |                 |             |
|                     | (Inventory, Core Modules|                 |             |
|                     |   & CIS Yaml Playbooks) |                 |             |
|                     +------------+------------+                 |             |
|                                  | (Generates HTML Logs)--------+             |
+----------------------------------|--------------------------------------------+
                                   |
                  [ Secure SSH Protocol (Port 22) ]
                                   |
    +------------------------------+------------------------------+
    |                              |                              |
+---v----------------+    +--------v-----------+    +-------------v------+
|    Target Host 1   |    |    Target Host 2   |    |    Target Host N   |
| (CentOS 7 - Zabbix)|    | (CentOS 7 - ELK)   |    | (CentOS 7 - Prom.) |
+--------------------+    +--------------------+    +--------------------+

Hệ thống công nghệ (Technology Stack) được chuẩn hóa với phiên bản chi tiết:

  • Hệ điều hành mục tiêu & Control Node: CentOS Linux release 7.9.2009 (Core)
  • Nền tảng Tự động hóa: Ansible Engine version 2.9+ (Python 3.6 runtime)
  • Quản trị CI/CD & Điều phối: Jenkins 2.x LTS (Java 11) & Ansible AWX 17.x
  • Cơ sở dữ liệu & Caching (AWX): PostgreSQL 12, Redis 6
  • Web Server phục vụ báo cáo: Nginx 1.20+
  • Kênh truyền thông & Xác thực: OpenSSH 7.4p1, SSH Keypair 4096-bit

Về mặt an toàn thông tin, hệ thống tuân thủ chặt chẽ nguyên tắc đặc quyền tối thiểu (Least Privilege). Quá trình thực thi sử dụng tài khoản có quyền sudo, bật cờ sudo pty và lưu trữ toàn bộ mật khẩu, SSH Key mã hóa trong tính năng Credentials của AWX/Jenkins.

Methodology

Dự án áp dụng phương pháp phát triển lặp (Iterative & Agile Methodology) kết hợp kiểm thử liên tục (Continuous Testing). Quy trình triển khai trải qua 4 cột mốc chính (Milestones):

  1. Phân tích CIS Benchmark & Trích xuất quy chuẩn: Lọc chọn hơn 85 khuyến nghị quan trọng từ bộ tiêu chuẩn CIS CentOS Linux 7 Benchmark v3.0.0 chia làm 6 phân vùng chuyên sâu.
  2. Module hóa Playbook: Thiết kế các Playbook dạng module hóa độc lập, tích hợp biến tags và vars_prompt để quản trị viên linh hoạt điều chỉnh tham số.
  3. Tích hợp CI/CD & Quản trị tập trung: Xây dựng Job Pipeline trên Jenkins và Workflow Template trên Ansible AWX.
  4. Thử nghiệm trên hạ tầng phân tán & Đánh giá rủi ro: Chạy thử nghiệm trên các máy ảo đóng vai trò Zabbix Server, ELK Stack, Prometheus Node và OpenVZ VPS.

Để kiểm soát rủi ro hệ thống, mỗi hành động thay đổi cấu hình đều tích hợp cơ chế kiểm tra điều kiện (when), tạo bản sao lưu cấu hình dự phòng (backup: yes) và phân tách rõ ràng hai chế độ: Chế độ Kiểm tra (Check Mode) và Chế độ Gia cố (Hardening Mode).

Implementation và kết quả

Development process

Quá trình hiện thực hóa được chia thành việc lập trình các Playbook YAML chuẩn hóa dựa trên các module cốt lõi của Ansible: lineinfile, stat, shell, file, service, yum, meta.

Toàn bộ 85+ tiêu chuẩn bảo mật được cấu trúc thành 6 phần (Parts):

  • Part 1: Initial Setup: Vô hiệu hóa các filesystem không dùng (cramfs, squashfs, udf), cấu hình sudo chạy trên pty và bắt buộc bật SELinux ở chế độ enforcing.
  • Part 2: Services: Tắt các dịch vụ legacy tiềm ẩn nguy cơ (chargen-dgram, daytime, echo, xinetd).
  • Part 3: Network Configuration: Vô hiệu hóa IP Forwarding, chặn ICMP Redirects, bật tính năng TCP SYN Cookies.
  • Part 4: Logging and Auditing: Cấu hình auditd và rsyslog ghi lại mọi hành vi chỉnh sửa quyền hệ thống và truy cập trái phép.
  • Part 5: Access, Authentication and Authorization: Gia cố máy chủ SSH Server (/etc/ssh/sshd_config), thiết lập chính sách mật khẩu mạnh với PAM.
  • Part 6: System Maintenance & Permissions: Rà soát và siết chặt phân quyền các file hệ thống trọng yếu (/etc/passwd, /etc/shadow, /etc/group).

Dưới đây là kỹ thuật triển khai điển hình cho tiêu chuẩn CIS 5.22: Đảm bảo số lượng SSH MaxSessions được giới hạn <= 10:

1. Playbook Kiểm tra (Check Security Playbook):

---
- hosts: all
  gather_facts: yes
  vars:
    path_to_log_check: "/var/www/html/reports/{{ inventory_hostname }}-{{ ansible_date_time.date }}.html"
    path_to_hardening: "http://192.168.1.100:8080/job/Hardening_CentOS7"

  tasks:
    - name: Get info SSH MaxSessions (Audit)
      shell: sshd -T | grep -i maxsessions | awk '$2 <= 10'
      register: session_check
      ignore_errors: yes

    - name: Get raw SSH MaxSessions value
      shell: sshd -T | grep -i maxsessions
      register: session_raw

    - name: Record Not Secure state to HTML Log
      local_action:
        module: lineinfile
        path: "{{ path_to_log_check }}"
        line: "<tr align='center'><td>SSH MaxSessions (<= 10)</td><td></td><td>x</td><td>{{ session_raw.stdout }}</td><td><a href='{{ path_to_hardening }}'>Click Here</a></td><td>h21</td></tr>"
      when: session_check.stdout == ""

    - name: Record Secure state to HTML Log
      local_action:
        module: lineinfile
        path: "{{ path_to_log_check }}"
        line: "<tr align='center'><td>SSH MaxSessions (<= 10)</td><td>v</td><td></td><td>{{ session_raw.stdout }}</td><td></td><td>h21</td></tr>"
      when: session_check.stdout != ""

2. Playbook Tự động hóa Gia cố (Hardening Playbook):

---
- hosts: all
  gather_facts: no
  tasks:
    - name: Ensure SSH MaxSessions is limited to 10 (Remediation 5.22)
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '(?i)^#?MaxSessions'
        line: 'MaxSessions 10'
        state: present
        validate: '/usr/sbin/sshd -t -f %s'
      tags: h21
      notify: Restart sshd

  handlers:
    - name: Restart sshd
      service:
        name: sshd
        state: restarted

Sự liên kết chặt chẽ nằm ở thẻ tags: h21: Quản trị viên khi xem báo cáo HTML thấy mục SSH MaxSessions bị đánh dấu x (Not Secure) kèm mã tag h21, có thể kích hoạt Job trên Jenkins/AWX và chỉ định chạy duy nhất tag h21 để khắc phục trong vài giây mà không cần chạy lại toàn bộ hệ thống Playbook.

Testing và validation

Nhóm tác giả đã thiết lập môi trường thử nghiệm đa máy chủ bao gồm:

  • Target 1: elk-stack (192.168.1.30) - Máy chủ lưu trữ log và giám sát.
  • Target 2: prometheus (192.168.1.31) - Máy chủ thu thập số liệu tải.
  • Target 3: zabbix (192.168.1.32) - Máy chủ giám sát hạ tầng mạng.
  • Target 4: vps-openvz (Internet Remote Node) - Máy chủ ảo hóa độc lập.

Kịch bản kiểm thử & Độ bao phủ (Coverage):

  • Kịch bản 1: Chạy toàn bộ Template "Check All" trên Ansible AWX để quét đồng thời 4 máy chủ.
  • Kịch bản 2: Thực thi "Hardening All" thông qua tính năng Workflow Templates trên AWX, tự động chuyển tiếp qua các Part từ 1 đến 6.
  • Kịch bản 3: Kiểm tra tính năng Selective Hardening trên Jenkins theo từng Part (Ví dụ: Part 6 System File Permissions) và kiểm tra tính năng gửi thông báo tức thời qua Telegram Bot API.

Kết quả kiểm thử cho thấy:

  • Tốc độ quét toàn bộ 85 tiêu chuẩn trên 4 máy chủ: 18 giây.
  • Tốc độ áp dụng gia cố tự động cho toàn bộ hệ thống: 42 giây.
  • Tỷ lệ thành công khi áp dụng cấu hình (Idempotency Success Rate): 100%. Không xảy ra xung đột dịch vụ hay mất kết nối SSH do cơ chế validate: '/usr/sbin/sshd -t -f %s'.

Kết quả đạt được

Hệ thống đã hoàn thành 100% các tính năng đề ra so với mục tiêu ban đầu:

  1. Xây dựng thành công bộ Playbook chuẩn hóa xử lý hơn 85 lỗ hổng phổ biến trên CentOS 7 theo chuẩn CIS.
  2. Tích hợp hoàn chỉnh trên cả 2 nền tảng Jenkins và Ansible AWX, đáp ứng đa dạng môi trường từ DevOps Pipeline đến Enterprise IT Administration.
  3. Tạo cơ chế báo cáo kép: File HTML/CSS trực quan lưu trữ tại Nginx Web Server và cảnh báo tự động về điện thoại quản trị viên qua Telegram Bot.
  4. Đảm bảo hiệu năng vượt trội: Giảm hơn 95% thời gian cấu hình bảo mật máy chủ so với phương pháp truyền thống.

Đổi mới và đóng góp

Đồ án mang lại nhiều cải tiến kỹ thuật thực tiễn:

  • Kiến trúc liên kết hai chiều (Two-Way Linked Feedback): Khắc phục nhược điểm của các script bảo mật thông thường (chạy mù quáng không báo cáo), đồ án kết nối trực tiếp giữa báo cáo quét HTML và thẻ Tags của Playbook gia cố, cho phép quản trị viên tùy biến khắc phục theo nhu cầu cụ thể (Granular Remediation).
  • Tiếp cận Zero-Agent: Khác với Puppet hay Chef đòi hỏi cài đặt Agent tốn từ 100-200MB RAM và duy trì cổng liên lạc mở trên máy chủ mục tiêu, giải pháp sử dụng Ansible tận dụng cơ sở hạ tầng SSH sẵn có, tuyệt đối an toàn và tiết kiệm tài nguyên.
Giải pháp so sánh Thời gian triển khai trên 10 Node Yêu cầu Agent Giao diện điều khiển & Báo cáo Độ an toàn khi cấu hình sai
Thao tác thủ công (Manual CLI) 300 - 600 phút Không Không có (Xem log thủ công) Rất rủi ro (Dễ khóa nhầm cổng)
Chef / InSpec Compliance 45 - 60 phút (Cần bootstrap) Có (Cài Chef Client) Có (Chef Automate - Phức tạp) Tốt nhưng phụ thuộc Agent
Giải pháp của Đồ án (Ansible + AWX/Jenkins) < 2 phút Không (Agentless) Có (AWX Dashboard + HTML Report + Telegram) Rất an toàn (Có cú pháp validate)

Đóng góp lớn nhất của đề tài là cung cấp một bộ công cụ mã nguồn mở hoàn chỉnh, có thể ứng dụng ngay lập tức vào các trung tâm dữ liệu, doanh nghiệp vừa và nhỏ (SMEs) hoặc các phòng lab thực hành an toàn thông tin tại các trường đại học.

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng thực tế

  1. Gia cố máy chủ mới triển khai (Day-0 Provisioning): Khi đội ngũ hạ tầng khởi tạo hàng loạt máy chủ ảo VPS/Cloud mới, Jenkins Pipeline tự động kích hoạt Playbook để đưa máy chủ về trạng thái an toàn chuẩn CIS trước khi bàn giao cho đội ngũ phát triển (Developers).
  2. Kiểm toán định kỳ (Periodic Compliance Audit): Thiết lập lịch chạy tự động (Cron Schedule trên AWX) vào 00:00 hàng tuần để quét toàn bộ máy chủ. Nếu phát hiện thay đổi cấu hình trái phép (Configuration Drift), hệ thống lập tức gửi cảnh báo Telegram cho đội SOC/NOC.

Hướng dẫn triển khai nhanh (Deployment Guide)

1. Yêu cầu hệ thống:

  • Control Server: CPU 2 Cores, 4GB RAM, 20GB Disk, CentOS 7 / Ubuntu 20.04 có cài sẵn Docker/Ansible.
  • Managed Hosts: CentOS 7, kích hoạt SSH, đã mở quyền sudo cho tài khoản quản trị.

2. Cài đặt và thực thi trên Control Server:

# Bước 1: Cài đặt Ansible và Git
sudo yum install epel-release -y
sudo yum install ansible git python-pip -y

# Bước 2: Clone repository đồ án
git clone https://github.com/project-hardening-centos/ansible-cis-hardening.git
cd ansible-cis-hardening

# Bước 3: Khai báo Inventory tại file hosts
cat <<EOF > hosts.ini
[servers]
elk-stack ansible_ssh_host=192.168.1.30 ansible_ssh_user=root
prometheus ansible_ssh_host=192.168.1.31 ansible_ssh_user=root
zabbix ansible_ssh_host=192.168.1.32 ansible_ssh_user=root
EOF

# Bước 4: Thực hiện quét toàn bộ hệ thống
ansible-playbook -i hosts.ini playbooks/check_security_all.yml

# Bước 5: Tiến hành gia cố các mục được chỉ định (Ví dụ Tag h21)
ansible-playbook -i hosts.ini playbooks/hardening_all.yml --tags "h21"

Phân tích Chi phí - Lợi ích (Cost-Benefit Analysis)

  • Chi phí bản quyền phần mềm: 0 VNĐ (100% sử dụng Open-Source: Ansible, Jenkins, AWX, Nginx, Linux).
  • Tiết kiệm thời gian: Giảm từ 45 giờ công lao động/tháng đối với cụm 50 máy chủ xuống còn chưa đầy 30 phút/tháng cho kỹ sư vận hành.
  • Thời gian hoàn vốn (ROI): Doanh nghiệp đạt điểm hòa vốn và thu hồi lợi ích vận hành ngay trong tháng đầu tiên triển khai.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Đồ án hiện tại tập trung tối ưu hóa chuyên biệt cho hệ điều hành CentOS 7; một số cú pháp cấu hình có thể khác biệt trên các phiên bản chạy systemd mới hơn hoặc họ Debian/Ubuntu.
  • Chưa hỗ trợ cơ chế Dynamic Inventory tự động phát hiện máy chủ trên các nền tảng Public Cloud (AWS EC2, Google Cloud Platform, Azure) theo tag thời gian thực.
  • Quản lý Secret Key trên file cấu hình tĩnh cần tiếp tục chuyển dịch hoàn toàn sang các dịch vụ HashiCorp Vault chuyên dụng.

Hướng phát triển trong tương lai

  • Mở rộng bộ Playbook để hỗ trợ đầy đủ các bản phân phối Linux hiện đại thay thế CentOS 7 như Rocky Linux 8/9, AlmaLinux và RHEL 9.
  • Tích hợp sâu vào hệ thống SIEM (Security Information and Event Management) như Wazuh hoặc Splunk để tự động kích hoạt Playbook cô lập máy chủ khi phát hiện tấn công.
  • Xây dựng Containerized All-in-one dưới dạng Docker Image giúp người dùng có thể kích hoạt Control Server chỉ bằng một dòng lệnh docker-compose up.

Đối tượng hưởng lợi

  • Sinh viên chuyên ngành An toàn thông tin & Mạng máy tính: Cung cấp tài liệu tham khảo thực tế về cách áp dụng lý thuyết CIS Benchmark vào mã nguồn Ansible thực thi được.
  • Kỹ sư Quản trị hệ thống (System Administrators) & DevOps: Sở hữu bộ khung Playbook chuẩn hóa có thể tích hợp ngay vào quy trình CI/CD để tự động hóa việc gia cố hạ tầng máy chủ.
  • Doanh nghiệp vừa và nhỏ (SMEs): Tiết kiệm hàng ngàn USD chi phí bản quyền giải pháp bảo mật đắt đỏ mà vẫn nâng cao năng lực phòng thủ hệ thống đạt chuẩn quốc tế.
  • Các nhà nghiên cứu An ninh mạng: Cung cấp dữ liệu thực nghiệm về thời gian xử lý, độ tin cậy và phương pháp kiểm thử an toàn trên hạ tầng máy chủ phân tán.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp này là gì?

Control Server cần cấu hình tối thiểu 2 Core CPU, 4GB RAM nếu chạy giao diện AWX (hoặc 1GB RAM nếu chạy Ansible Core CLI thuần túy). Các máy chủ Remote Host chỉ cần cài đặt hệ điều hành CentOS 7, mở cổng SSH (Port 22) và có sẵn môi trường Python 2.7 hoặc Python 3.6 trở lên.

2. Hệ thống có khả năng mở rộng (Scalability) quản lý bao nhiêu máy chủ cùng lúc?

Ansible cho phép cấu hình tham số forks trong file ansible.cfg (mặc định là 5, có thể tăng lên 50 - 100 tùy thuộc vào CPU/Băng thông của Control Server). Khi kết hợp cùng tính năng Workflow Queue của AWX, hệ thống có khả năng kiểm tra và cấu hình đồng thời hàng trăm máy chủ trong vài phút.

3. Việc chạy Playbook gia cố có nguy cơ làm gián đoạn các ứng dụng đang chạy không?

Rủi ro được giảm thiểu tối đa nhờ việc phân tách rõ ràng giữa chế độ quét (Audit) và chế độ gia cố (Remediation). Ngoài ra, các task can thiệp vào file cấu hình dịch vụ nhạy cảm (như SSH hoặc Web Server) đều tích hợp lệnh validate cú pháp trước khi ghi đè, tránh tình trạng dịch vụ bị sập do lỗi cấu hình.

4. Chi phí duy trì và bảo trì hệ thống hàng tháng là bao nhiêu?

Hệ thống được xây dựng hoàn toàn trên các nền tảng mã nguồn mở (Ansible, AWX, Jenkins, PostgreSQL, Nginx) nên chi phí bản quyền là 0 đồng. Doanh nghiệp chỉ chi trả chi phí vận hành phần cứng của máy chủ Control Node.

5. Có thể áp dụng giải pháp này cho các hệ điều hành khác như Ubuntu hay Red Hat Enterprise Linux không?

Kiến trúc Playbook của Ansible hoàn toàn hỗ trợ đa nền tảng. Với RHEL 7/8, các Playbook của đề tài có thể tương thích trực tiếp tới hơn 95%. Với Ubuntu/Debian, quản trị viên chỉ cần điều chỉnh các module quản lý gói từ yum sang apt và thay đổi một số đường dẫn file cấu hình tương ứng.

Kết luận

Đồ án tốt nghiệp "Tự động hóa cấu hình và nâng cao tính bảo mật cho hệ điều hành CentOS" của nhóm tác giả Huỳnh Minh Thái và Phạm Nguyễn Hữu Tân đã giải quyết thành công một trong những bài toán cấp thiết nhất của quản trị an toàn thông tin hiện đại: chuyển dịch từ quy trình bảo mật thủ công, rời rạc sang mô hình bảo mật tự động hóa, tập trung và có thể kiểm toán được.

Bằng việc kết hợp sức mạnh của tiêu chuẩn quốc tế CIS Benchmark, công nghệ tự động hóa Agentless Ansible cùng giao diện điều phối trực quan Jenkins/AWX, đề tài đã chứng minh tính khả thi vượt trội với thời gian triển khai giảm hơn 95% và độ tin cậy đạt 100%. Đây là nền tảng vững chắc để tiếp tục mở rộng sang các hệ điều hành thế hệ mới, đóng góp thiết thực cho cộng đồng quản trị hệ thống và an ninh mạng tại Việt Nam.