Tài liệu Hướng dẫn Sử dụng OCN Firewall¶

Phiên bản: 1.0 (Bản nháp) Đối tượng: Quản trị viên hệ thống OCN Firewall

Chào mừng bạn đến với OCN Firewall!

Tài liệu này là hướng dẫn toàn diện dành cho quản trị viên hệ thống chịu trách nhiệm triển khai, cấu hình, quản lý và bảo trì OCN Firewall. Chúng tôi sẽ cung cấp cho bạn thông tin chi tiết, hướng dẫn từng bước và các phương pháp tốt nhất để vận hành hệ thống một cách hiệu quả và an toàn.

Mục lục¶

Tài liệu Hướng dẫn Sử dụng OCN Firewall
Mục lục
1. Giới thiệu
2. Cài đặt và Triển khai
3. Quản lý Người dùng
4. Quản lý Máy chủ (Servers)
5. Quản lý Chính sách Hệ thống (System Policies)
6. Sao lưu và Phục hồi
7. Giám sát và Bảo trì
8. Bảo mật Nâng cao
9. Khắc phục sự cố (Troubleshooting)
10. Phụ lục
- 10.1 Thuật ngữ

1. Giới thiệu¶

1.1 OCN Firewall là gì?¶

OCN Firewall là một hệ thống tường lửa tập trung, dựa trên phần mềm, được thiết kế để quản lý và thực thi các chính sách bảo mật mạng trên nhiều máy chủ (servers) trong hạ tầng của bạn. Nó cho phép bạn định nghĩa các quy tắc tường lửa một cách linh hoạt thông qua API Server trung tâm và tự động áp dụng chúng xuống các Agent được cài đặt trên từng máy chủ.

1.2 Các thành phần chính¶

API Server (Firewalld): Trung tâm điều khiển của hệ thống. Nó quản lý cấu hình, chính sách, người dùng, máy chủ và giao tiếp với các Agent. Nó cũng cung cấp API RESTful và giao diện dòng lệnh (CLI) để quản trị.
Agent (ocn-firewall-agent): Chương trình chạy trên mỗi máy chủ cần được bảo vệ. Agent kết nối với API Server, nhận cấu hình và chính sách, sau đó áp dụng chúng vào hệ thống tường lửa của máy chủ (ví dụ: iptables/nftables trên Linux, Windows Firewall).
MongoDB: Cơ sở dữ liệu được sử dụng bởi API Server để lưu trữ tất cả dữ liệu cấu hình, bao gồm thông tin người dùng, máy chủ, chính sách, zone, v.v.
CLI (ocnfwctl): Công cụ giao diện dòng lệnh cho phép quản trị viên tương tác với API Server để quản lý hệ thống.
Dashboard: Giao diện web (thường được cung cấp bởi API Server) để quản lý và giám sát tập trung.

1.3 Đối tượng sử dụng tài liệu này¶

Tài liệu này dành cho:

Quản trị viên hệ thống chịu trách nhiệm triển khai và quản lý OCN Firewall.
Kỹ sư an ninh mạng cần thiết lập và quản lý chính sách bảo mật.
Chuyên gia vận hành hạ tầng cần giám sát và xử lý sự cố hệ thống.

1.4 Kiến thức và kỹ năng cần thiết¶

Để quản trị hiệu quả OCN Firewall, bạn nên có:

Kiến thức vững chắc về mạng (TCP/IP, CIDR, Ports) và bảo mật.
Kinh nghiệm quản trị hệ điều hành Linux và/hoặc Windows.
Hiểu biết cơ bản về cách hoạt động của tường lửa (iptables, nftables, Windows Firewall).
Hiểu biết cơ bản về MongoDB là một lợi thế.
Kinh nghiệm với Docker và Docker Compose nếu bạn chọn triển khai bằng container.

2. Cài đặt và Triển khai¶

Phần này hướng dẫn bạn cách cài đặt và triển khai các thành phần của OCN Firewall.

2.1 Yêu cầu hệ thống¶

Vui lòng tham khảo chi tiết yêu cầu phần cứng và phần mềm cho từng thành phần (API Server, MongoDB, Agent) trong tài liệu deployment.md được cung cấp. Đảm bảo các máy chủ đáp ứng đủ tài nguyên (CPU, RAM, Disk) và các phần mềm phụ thuộc cần thiết.

2.2 Mô hình triển khai¶

OCN Firewall hỗ trợ hai mô hình chính:

Triển khai đơn lẻ: Phù hợp cho môi trường nhỏ hoặc thử nghiệm. API Server và MongoDB có thể chạy trên cùng một máy chủ hoặc các máy chủ riêng biệt.

+---------------+      +-----------------+
|  API Server   |<---->|    MongoDB     |
+-------+-------+      +-----------------+
        ^
        |
        v
+-------+-------+
|    Agents     |
+---------------+

Triển khai High Availability (HA): Khuyến nghị cho môi trường sản xuất lớn, đảm bảo tính sẵn sàng cao. Sử dụng MongoDB Replica Set và nhiều instance API Server phía sau một Load Balancer.

+---------------+      +-----------------+
|  Load         |      |   MongoDB      |
|  Balancer     |<---->|   Replica Set  |
+-------+-------+      +-------+---------+
        ^                      ^
        |                      |
        v                      v
+-------+-------+      +-------+-------+
|  API Server 1 |<---->|  API Server 2 |
+-------+-------+      +---------------+
        ^                      ^
        |                      |
        v                      v
+-------+-------+      +-----------------+
|    Agents     |<---->|    Agents      |
+---------------+      +-----------------+

2.3 Triển khai API Server (Firewalld)¶

Bạn có thể triển khai API Server bằng Docker (khuyến nghị) hoặc cài đặt thủ công.

2.3.1 Sử dụng Docker (Khuyến nghị)¶

Đây là phương pháp đơn giản và nhất quán nhất để triển khai API Server và MongoDB.

Chuẩn bị: Cài đặt Docker và Docker Compose trên máy chủ đích.
Tạo thư mục: mkdir -p /opt/ocn-firewall && cd /opt/ocn-firewall
Tạo docker-compose.yaml: Sao chép nội dung file docker-compose.yaml từ tài liệu deployment.md. File này định nghĩa các dịch vụ firewalld và mongodb.
- Lưu ý: Đảm bảo image registry.ocn.com.vn/firewall/firewalld:latest là chính xác và có thể truy cập.
Tạo file .env: Tạo file .env trong cùng thư mục /opt/ocn-firewall và định nghĩa các biến môi trường nhạy cảm như MONGO_ROOT_PASSWORD, MONGO_PASSWORD, JWT_SECRET, ENCRYPT_KEY. Sử dụng mật khẩu mạnh và key bí mật.
Tạo mongo-init.js: Sao chép nội dung file mongo-init.js từ deployment.md. File này sẽ được MongoDB sử dụng để:
- Tạo database firewall.
- Tạo người dùng firewall_user với quyền truy cập vào database.
- Tạo tài khoản admin mặc định (Quan trọng: Thay thế $2a$10$YourHashedPasswordHere bằng hash bcrypt của mật khẩu bạn muốn đặt, ví dụ: admin123). Bạn có thể tạo hash online hoặc dùng thư viện lập trình.
- Tạo các Zone mặc định (internet, private).
Khởi động: Chạy lệnh docker-compose up -d trong thư mục /opt/ocn-firewall.
Kiểm tra: Sử dụng docker-compose ps để xem trạng thái các container và docker-compose logs -f firewalld để theo dõi log của API Server.

2.3.2 Triển khai thủ công¶

Nếu không sử dụng Docker, bạn cần cài đặt và cấu hình từng thành phần riêng biệt.

Cài đặt MongoDB: Thực hiện theo hướng dẫn cài đặt MongoDB (phiên bản 7.0+) cho hệ điều hành của bạn (tham khảo deployment.md cho ví dụ trên Ubuntu).
Bảo mật MongoDB:
- Tạo người dùng root cho MongoDB.
- Bật chế độ xác thực (security.authorization: enabled trong /etc/mongod.conf).
- Khởi động lại MongoDB.
Tạo Database và User cho OCN Firewall: Kết nối vào MongoDB bằng tài khoản root, tạo database firewall, tạo user firewall_user với quyền readWrite trên database firewall. Đồng thời, tạo tài khoản admin và các Zone mặc định như trong file mongo-init.js.
Tải và Cài đặt API Server: Tải file thực thi firewalld từ nguồn cung cấp (ví dụ: wget ...) và đặt nó vào /usr/local/bin/firewalld. Cấp quyền thực thi (chmod +x).
Tạo File Cấu hình: Tạo /etc/ocn-firewall/config.env và điền các biến môi trường cần thiết như DB_URI (sử dụng thông tin user/password đã tạo ở bước 3), USER_TOKEN_SECRET_KEY, ENCRYPT_KEY, v.v. (tham khảo deployment.md).
Tạo Dịch vụ Systemd: Tạo file /etc/systemd/system/firewalld.service (nội dung tham khảo deployment.md) để quản lý tiến trình API Server.
Khởi động Dịch vụ: Chạy sudo systemctl daemon-reload, sudo systemctl enable firewalld, sudo systemctl start firewalld. Kiểm tra trạng thái bằng sudo systemctl status firewalld và xem log bằng sudo journalctl -u firewalld -f.

2.4 Triển khai Agent¶

Agent cần được cài đặt trên mọi máy chủ mà bạn muốn quản lý bằng OCN Firewall.

2.4.1 Trên Linux¶

Tải Agent: Tải file thực thi ocn-firewall-agent (ví dụ: wget ...) và đặt vào /usr/local/bin/ocn-firewall-agent. Cấp quyền thực thi (chmod +x).
Tạo File Cấu hình (Tùy chọn): Tạo /etc/ocn-firewall/agent.env nếu bạn muốn tùy chỉnh các cài đặt như LOG_LEVEL, IPTABLES_LOCK_SECONDS_TIMEOUT, v.v.
Tạo Dịch vụ Systemd: Tạo file /etc/systemd/system/ocn-firewall-agent.service. Sao chép nội dung từ deployment.md và quan trọng là thay thế các placeholder:
- %GROUP_NAME%: Tên nhóm logic cho máy chủ này (ví dụ: web-servers, db-servers).
- %SERVER_IP%: Địa chỉ IP mà Agent nên báo cáo cho API Server (thường là IP chính của máy chủ).
- %API_SERVER_ADDRESS%: Địa chỉ IP hoặc hostname của API Server (hoặc Load Balancer nếu dùng HA).
- %AGENT_TOKEN%: Token xác thực Agent. Token này có thể được tạo thủ công trên API Server hoặc sử dụng token đăng ký tự động (xem phần Quản lý Máy chủ).
Khởi động Dịch vụ: Chạy sudo systemctl daemon-reload, sudo systemctl enable ocn-firewall-agent, sudo systemctl start ocn-firewall-agent. Kiểm tra trạng thái bằng sudo systemctl status ocn-firewall-agent và log bằng sudo journalctl -u ocn-firewall-agent -f.

2.4.2 Trên Windows¶

Tải Agent: Tải file thực thi ocn-firewall-agent-windows-amd64.exe.
Tạo Thư mục Cài đặt: Tạo thư mục C:\Program Files\OCN Firewall.
Di chuyển File Thực thi: Đổi tên và di chuyển file đã tải vào C:\Program Files\OCN Firewall\ocn-firewall-agent.exe.
Tạo File Cấu hình (Tùy chọn): Tạo C:\Program Files\OCN Firewall\agent.env nếu cần tùy chỉnh.
Tạo Dịch vụ Windows: Mở PowerShell với quyền Administrator và chạy lệnh sc.exe create ... như trong deployment.md. Quan trọng: Thay thế các placeholder GROUP_NAME, SERVER_IP, API_SERVER_ADDRESS, AGENT_TOKEN tương tự như trên Linux.
Cấu hình và Khởi động: Cấu hình dịch vụ tự động khởi động và khởi động nó:
```
sc.exe config "OCNFirewallAgent" start=auto
sc.exe start "OCNFirewallAgent"
```
Kiểm tra: Kiểm tra trạng thái dịch vụ trong services.msc và xem log trong Event Viewer (Application Log, source “OCNFirewallAgent”).

2.5 Triển khai High Availability (HA)¶

Để đạt được HA, bạn cần:

Cấu hình MongoDB Replica Set:
- Chuẩn bị ít nhất 3 máy chủ MongoDB.
- Cài đặt MongoDB trên tất cả các máy chủ.
- Cấu hình replication.replSetName và net.bindIp: 0.0.0.0 trong /etc/mongod.conf trên mỗi node. Bật security.authorization: enabled.
- Khởi động lại MongoDB trên tất cả các node.
- Kết nối vào một node và chạy rs.initiate(...) để khởi tạo Replica Set, chỉ định các thành viên.
- Tạo người dùng root và firewall_user như trong triển khai thủ công (chỉ cần làm trên Primary node, dữ liệu sẽ được nhân bản).
Triển khai nhiều API Server Instances: Cài đặt API Server (Docker hoặc thủ công) trên ít nhất hai máy chủ khác nhau.
Cấu hình API Server sử dụng Replica Set: Trong file cấu hình (.env hoặc config.env) của mỗi API Server instance, cập nhật DB_URI để trỏ đến Replica Set:
```
DB_URI=mongodb://firewall_user:YourPassword@mongo1:27017,mongo2:27017,mongo3:27017/firewall?replicaSet=ocnfirewall&authSource=firewall
```
(Thay mongo1, mongo2, mongo3 và YourPassword, ocnfirewall bằng thông tin thực tế).
Cấu hình Load Balancer:
- Cài đặt một bộ cân bằng tải (ví dụ: Nginx, HAProxy) phía trước các API Server instances.
- Cấu hình Load Balancer để chuyển tiếp các kết nối đến cổng 8080 của các API Server instances đang hoạt động (tham khảo cấu hình Nginx mẫu trong deployment.md).
- Cấu hình Agent để trỏ đến địa chỉ của Load Balancer thay vì địa chỉ của một API Server cụ thể.

2.6 Kiểm tra sau triển khai¶

Sau khi cài đặt xong, hãy thực hiện các kiểm tra cơ bản:

Kiểm tra API Server Health:

curl http://<API_SERVER_ADDRESS>:8080/api/v1/health
# Mong đợi kết quả JSON chứa "status": "UP" hoặc tương tự

[Đề xuất chèn ảnh chụp màn hình kết quả curl health check thành công]

Kiểm tra kết nối MongoDB: (Nếu cài đặt thủ công)

mongosh "mongodb://firewall_user:YourPassword@<MONGODB_ADDRESS>:27017/firewall?authSource=firewall"
# Mong đợi kết nối thành công

Kiểm tra Log: Theo dõi log của API Server và Agent để phát hiện lỗi sớm.

2.7 Cấu hình CLI (ocnfwctl)¶

Công cụ ocnfwctl là giao diện chính để bạn quản trị OCN Firewall.

Tải và Cài đặt CLI: Tải file thực thi ocnfwctl phù hợp với hệ điều hành của bạn và đặt nó vào đường dẫn hệ thống (ví dụ: /usr/local/bin/). Cấp quyền thực thi nếu cần.

Cấu hình Kết nối: Cho ocnfwctl biết địa chỉ API Server của bạn:

ocnfwctl config set-server http://<API_SERVER_ADDRESS>:8080
# Thay <API_SERVER_ADDRESS> bằng địa chỉ IP hoặc hostname của API Server hoặc Load Balancer

Đăng nhập: Đăng nhập bằng tài khoản quản trị viên bạn đã tạo (hoặc tài khoản mặc định nếu chưa đổi):
```
ocnfwctl login
# Nhập username: admin
# Nhập password: (Mật khẩu bạn đã đặt hoặc mật khẩu mặc định ban đầu)
```
[Đề xuất chèn ảnh chụp màn hình quá trình đăng nhập ocnfwctl]
Kiểm tra: Thử một lệnh đơn giản để xác nhận kết nối và xác thực:
```
ocnfwctl server list
# Ban đầu danh sách sẽ trống
```

2.8 Đổi mật khẩu Admin mặc định¶

Rất quan trọng: Nếu bạn đã sử dụng mật khẩu mặc định trong quá trình cài đặt, hãy đổi nó ngay lập tức sau lần đăng nhập đầu tiên để đảm bảo an toàn.

# Đăng nhập bằng tài khoản admin trước
ocnfwctl login

# Đổi mật khẩu
ocnfwctl user set-password --username admin --new-password "NewStrongSecurePassword123!"

Hoặc bạn có thể yêu cầu người dùng admin tự đổi:

ocnfwctl user change-password --old-password "OldDefaultPassword" --new-password "NewStrongSecurePassword123!"

3. Quản lý Người dùng¶

Phần này mô tả cách quản lý tài khoản người dùng và quyền truy cập trong OCN Firewall.

3.1 Tổng quan về vai trò (Roles)¶

OCN Firewall sử dụng RBAC (Role-Based Access Control) để quản lý quyền hạn:

admin: Toàn quyền quản trị hệ thống, bao gồm quản lý người dùng, chính sách, máy chủ, và cấu hình hệ thống.
operator: Có quyền quản lý chính sách và máy chủ, xem thông tin, nhưng không thể quản lý người dùng hoặc cấu hình hệ thống cốt lõi.
viewer: Chỉ có quyền xem thông tin (read-only). Không thể thực hiện thay đổi.
custom: (Nếu hệ thống hỗ trợ) Vai trò tùy chỉnh với bộ quyền hạn cụ thể.

3.2 Quản lý người dùng qua CLI¶

Sử dụng ocnfwctl user để thực hiện các thao tác quản lý người dùng (yêu cầu quyền admin).

Liệt kê người dùng:

ocnfwctl user list [--role <role_name>]

Xem chi tiết người dùng:

ocnfwctl user get --username <username>

Tạo người dùng mới:

ocnfwctl user create --username <username> --password "<password>" --role <role> [--fullname "<full_name>"] [--email "<email>"] [--phone "<phone>"]
# Ví dụ:
ocnfwctl user create --username jdoe --password "SecurePass123$" --role operator --fullname "Jane Doe" --email "jane.doe@example.com"

Cập nhật thông tin: (Không cập nhật username, password, role ở đây)

ocnfwctl user update --username <username> [--fullname "<full_name>"] [--email "<email>"] [--phone "<phone>"]

Đặt lại mật khẩu: (Admin đặt lại cho người khác)

ocnfwctl user set-password --username <username> --new-password "<new_password>"

Thay đổi mật khẩu: (Người dùng tự thay đổi)

ocnfwctl user change-password --old-password "<old_password>" --new-password "<new_password>"

Thay đổi vai trò:

ocnfwctl user set-role --username <username> --role <new_role>

Vô hiệu hóa tài khoản:

ocnfwctl user disable --username <username>

Kích hoạt tài khoản:

ocnfwctl user enable --username <username>

Xóa người dùng:

ocnfwctl user delete --username <username>

3.3 Quản lý người dùng qua API¶

Các endpoint API RESTful tương ứng cũng có sẵn để tự động hóa hoặc tích hợp. Tham khảo tài liệu user-management.md hoặc tài liệu API chi tiết (nếu có) cho các endpoint như:

GET /api/v1/users
POST /api/v1/users
GET /api/v1/users/{username}
PUT /api/v1/users/{username}
DELETE /api/v1/users/{username}
PATCH /api/v1/users/{username}/role
… và các API khác cho 2FA, password, status.

3.4 Xác thực hai yếu tố (2FA)¶

Tăng cường bảo mật bằng cách yêu cầu 2FA (TOTP) khi đăng nhập.

Người dùng tự bật 2FA:
1. ocnfwctl user enable-2fa (Hiển thị QR code và recovery code)
2. Quét QR code bằng ứng dụng Authenticator (Google Auth, Authy, etc.)
3. ocnfwctl user verify-2fa --code <6_digit_code> (Xác nhận bằng mã từ app) [Đề xuất chèn ảnh chụp màn hình mã QR và quá trình verify 2FA]

Người dùng tự tắt 2FA:

ocnfwctl user disable-2fa --code <6_digit_code>

Admin tắt 2FA cho người dùng: (Khi người dùng mất thiết bị)
```
ocnfwctl user admin-disable-2fa --username <username>
```
Admin đặt lại 2FA cho người dùng: (Yêu cầu người dùng thiết lập lại từ đầu)
```
ocnfwctl user reset-2fa --username <username>
```

3.5 Quản lý phiên đăng nhập¶

Xem trạng thái đăng nhập hiện tại:
```
ocnfwctl auth status
```
Đăng xuất phiên hiện tại:
```
ocnfwctl auth logout
```
Đăng xuất tất cả các phiên của bạn:
```
ocnfwctl auth logout-all
```

Admin buộc đăng xuất người dùng khác:

ocnfwctl user logout --username <username>

3.6 Chính sách mật khẩu¶

OCN Firewall thường có chính sách mật khẩu tích hợp (độ dài, độ phức tạp, lịch sử). Đảm bảo người dùng tuân thủ các chính sách này khi tạo hoặc thay đổi mật khẩu. Quản trị viên có thể tùy chỉnh các chính sách này trong cấu hình API Server (nếu được hỗ trợ).

3.7 Kiểm tra và Ghi nhật ký¶

Mọi hành động quản lý người dùng đều được ghi lại. Sử dụng lệnh sau để xem log:

ocnfwctl logs list --resource user [--resource-id <username>]

4. Quản lý Máy chủ (Servers)¶

Phần này giải thích cách quản lý các máy chủ (nơi Agent được cài đặt) trong OCN Firewall.

4.1 Tổng quan¶

Máy chủ trong OCN Firewall là các node đã cài đặt Agent và đăng ký thành công với API Server. Quản lý máy chủ bao gồm việc theo dõi trạng thái, áp dụng chính sách thông qua nhãn và nhóm, và xem thông tin chi tiết.

4.2 Đăng ký máy chủ¶

Khi Agent khởi động và kết nối lần đầu với API Server bằng một token hợp lệ, nó sẽ tự động đăng ký.

Đăng ký thủ công (Sử dụng token cố định): Bạn có thể tạo một token không hết hạn (hoặc hết hạn dài) trên API Server và cấu hình token đó trực tiếp trong file dịch vụ systemd/Windows service của Agent (-token "your-long-lived-token"). Cách này đơn giản nhưng kém an toàn hơn.
Đăng ký tự động (Sử dụng token đăng ký tạm thời): Đây là cách an toàn và linh hoạt hơn, đặc biệt khi tự động hóa triển khai Agent.
1. Tạo Token Đăng ký trên API Server:
```
# Tạo token cho Agent thuộc nhóm 'web-servers', hết hạn sau 2 ngày
ocnfwctl server create-token --groupname "web-servers" --expires-in 48h
# Lệnh này sẽ trả về một token tạm thời
```
2. Sử dụng Token để Khởi động Agent: Cấu hình Agent để sử dụng token này khi khởi động lần đầu:
```
# Ví dụ trong file systemd service
ExecStart=/usr/local/bin/ocn-firewall-agent ... -token "registration-token-generated-above"
```
  Agent sẽ dùng token này để đăng ký, nhận ID và token hoạt động dài hạn từ API Server. Sau khi đăng ký thành công, token đăng ký tạm thời sẽ không còn giá trị.

4.3 Quản lý máy chủ qua CLI¶

Sử dụng ocnfwctl server để quản lý các máy chủ đã đăng ký.

Liệt kê máy chủ:

ocnfwctl server list [--group <groupname>] [--status <online|offline>] [--label <key=value>] [--columns <col1,col2,...>]
# Ví dụ xem ID, hostname, status, IP
ocnfwctl server list --columns id,hostname,status,ip

[Đề xuất chèn ảnh chụp màn hình kết quảocnfwctl server list]

Xem chi tiết máy chủ:

ocnfwctl server get --id <server_id>
# Hoặc dùng --ip <ip_address> hoặc --hostname <hostname>

Cập nhật thông tin máy chủ: (Ví dụ: đổi nhóm)

ocnfwctl server update --id <server_id> --groupname "new-group-name"

Xóa máy chủ: (Chỉ xóa khỏi API Server, không gỡ Agent)

ocnfwctl server delete --id <server_id>
# Lưu ý: Nên dừng Agent trên máy chủ trước khi xóa khỏi API Server.

4.4 Sử dụng Nhãn (Labels) và Nhóm (Groups)¶

Nhãn và Nhóm là cơ chế cốt lõi để áp dụng chính sách một cách linh hoạt.

Nhóm (Groupname): Một thuộc tính chính của máy chủ, thường được đặt khi Agent đăng ký (ví dụ: web-servers, db-servers, production, staging). Một máy chủ chỉ thuộc về một nhóm tại một thời điểm.
Nhãn (Labels): Các cặp key-value tùy ý bạn có thể gán cho máy chủ để phân loại chi tiết hơn (ví dụ: env=production, app=backend, dc=us-east-1, os=ubuntu). Một máy chủ có thể có nhiều nhãn. Nhãn rất quan trọng khi định nghĩa selector trong chính sách.

Gắn nhãn cho máy chủ:

ocnfwctl server label --id <server_id> --label <key1=value1> --label <key2=value2>
# Ví dụ:
ocnfwctl server label --id server-abc-123 --label env=production --label tier=frontend

Xóa nhãn:

ocnfwctl server unlabel --id <server_id> --label <key_to_remove>

Liệt kê các nhóm hiện có:
```
ocnfwctl server groups
```

Đổi tên nhóm cho nhiều máy chủ:

ocnfwctl server group-rename --old-name "old-group" --new-name "new-group"

4.5 Giám sát trạng thái máy chủ¶

Kiểm tra trạng thái kết nối:

ocnfwctl server list --columns id,hostname,ip,status,lastHeartbeat
# 'status' sẽ là 'online' hoặc 'offline'
# 'lastHeartbeat' cho biết thời gian cuối cùng Agent gửi tín hiệu

Kiểm tra phiên bản Agent:

ocnfwctl server list --columns id,hostname,version

Xem lịch sử trạng thái: (Xem khi nào máy chủ online/offline)
```
ocnfwctl server history --id <server_id>
```
Xem thông tin chi tiết Agent: (Cấu hình, trạng thái datastore/dataplane)
```
ocnfwctl server agent-info --id <server_id>
```

Kiểm tra trạng thái áp dụng chính sách:

ocnfwctl server policy-status --id <server_id>

Buộc đồng bộ lại chính sách: (Yêu cầu Agent lấy lại chính sách từ API Server)
```
ocnfwctl server sync-policies --id <server_id>
```

4.6 Thống kê và báo cáo¶

Xem thống kê sử dụng chính sách: (Xem rule nào được sử dụng nhiều)
```
ocnfwctl server stats --id <server_id>
```

Xem nhật ký sự kiện liên quan đến máy chủ:

ocnfwctl logs list --resource server --resource-id <server_id>

4.7 Quản lý máy chủ qua API¶

Tương tự quản lý người dùng, bạn có thể dùng API để quản lý máy chủ. Tham khảo server-management.md hoặc tài liệu API cho các endpoint như:

GET /api/v1/servers
POST /api/v1/servers/tokens (Tạo token đăng ký)
GET /api/v1/servers/{id}
PUT /api/v1/servers/{id} (Cập nhật nhóm, nhãn)
DELETE /api/v1/servers/{id}

4.8 Quản lý tập trung qua Dashboard¶

Nếu hệ thống có Dashboard, bạn có thể truy cập nó qua trình duyệt tại địa chỉ API Server (thường là http://<API_SERVER_ADDRESS>:8080/dashboard). Dashboard cung cấp cái nhìn tổng quan về trạng thái máy chủ, chính sách, và các thông tin giám sát khác. [Đề xuất chèn ảnh chụp màn hình giao diện Dashboard chính]

5. Quản lý Chính sách Hệ thống (System Policies)¶

Đây là phần cốt lõi của OCN Firewall, nơi bạn định nghĩa các quy tắc kiểm soát lưu lượng mạng.

5.1 Tổng quan về chính sách¶

Một chính sách (Policy) trong OCN Firewall là một đối tượng xác định:

Metadata: Tên (name), mô tả (description), nhãn (labels) cho chính sách.
Selector: Một biểu thức logic (dựa trên nhãn và nhóm của máy chủ) để xác định máy chủ nào sẽ áp dụng chính sách này.
Thứ tự ưu tiên (Order): Một số nguyên xác định thứ tự áp dụng chính sách khi nhiều chính sách cùng khớp với một máy chủ (số nhỏ hơn = ưu tiên cao hơn).
Quy tắc vào (Ingress): Danh sách các quy tắc kiểm soát lưu lượng đi vào các máy chủ được chọn bởi selector.
Quy tắc ra (Egress): Danh sách các quy tắc kiểm soát lưu lượng đi ra từ các máy chủ được chọn bởi selector.

Mỗi quy tắc (Rule) trong Ingress hoặc Egress thường bao gồm:

Nguồn/Đích (From/To): Xác định nguồn (cho Ingress) hoặc đích (cho Egress) của lưu lượng. Có thể là:
- Một selector khác (ví dụ: group=db-servers, env=production).
- Một dải địa chỉ CIDR (ví dụ: 192.168.1.0/24, 10.0.0.0/8).
- Một Zone được định nghĩa trước (ví dụ: internet, private).
Cổng (Ports): Danh sách các cổng hoặc dải cổng (ví dụ: 80, 443, 3000-3010).
Giao thức (Protocol): tcp, udp, icmp.
Hành động (Action): allow (cho phép) hoặc deny (từ chối).

5.2 Làm việc với chính sách (CLI)¶

Sử dụng ocnfwctl policy để quản lý chính sách.

Liệt kê chính sách:

ocnfwctl policy list [--selector <selector_expression>] [--label <key=value>]

Xem chi tiết chính sách:

ocnfwctl policy get --id <policy_id_or_name>

Tạo/Cập nhật chính sách từ file YAML: (Phương pháp khuyến nghị)

Tạo file YAML định nghĩa chính sách (xem ví dụ trong system-policy.md).

# Ví dụ: allow-http-https.yaml
name: allow-web-traffic
description: "Allow HTTP and HTTPS ingress from internet"
spec:
  selector: "group=web-servers" # Áp dụng cho máy chủ nhóm web-servers
  order: 100
  ingress:
    - from:
        - selector: "internet" # Zone internet
      ports:
        - 80
        - 443
      protocol: tcp
      action: allow
  egress: # Ví dụ: cho phép mọi egress (có thể hạn chế hơn)
    - to:
        - selector: "*"
      action: allow

Áp dụng file:

ocnfwctl policy apply -f allow-http-https.yaml
# Lệnh này sẽ tạo mới nếu chưa có, hoặc cập nhật nếu đã tồn tại chính sách cùng tên

[Đề xuất chèn ảnh chụp màn hình ví dụ file YAML]

Tạo chính sách trực tiếp qua CLI: (Phù hợp cho chính sách đơn giản)

ocnfwctl policy create --name <name> --selector "<selector>" --order <order> \
  --ingress-from <selector/cidr/zone> --ingress-ports <ports> --ingress-protocol <proto> --ingress-action <allow/deny> \
  [--egress-to ...] # Tương tự cho egress
# Ví dụ:
ocnfwctl policy create --name deny-ssh-from-internet --selector "*" --order 10 \
  --ingress-from "internet" --ingress-ports 22 --ingress-protocol tcp --ingress-action deny

Cập nhật chính sách: (Cập nhật metadata, order)

ocnfwctl policy update --id <policy_id_or_name> [--description "<desc>"] [--order <new_order>]

Cập nhật quy tắc trong chính sách: (Cập nhật rule hiện có)

# Cập nhật rule ingress đầu tiên (index 0)
ocnfwctl policy update-rule --id <policy_id> --ingress-index 0 --ingress-ports 80,443,8080

Xóa chính sách:

ocnfwctl policy delete --id <policy_id_or_name>

Xóa quy tắc khỏi chính sách:

ocnfwctl policy delete-rule --id <policy_id> --ingress-index <index>
# Hoặc --egress-index <index>

5.3 Các loại chính sách hệ thống¶

Bạn có thể tạo nhiều loại chính sách để đáp ứng các nhu cầu khác nhau:

Chính sách Mặc định (Default Policy): Sử dụng selector "*" và order cao (ví dụ: 999) để áp dụng cho tất cả máy chủ nếu không có chính sách cụ thể nào khác khớp. Thường dùng để thiết lập quy tắc cơ bản (ví dụ: cho phép ICMP, từ chối mọi thứ khác).
Chính sách Theo Nhóm/Vai trò: Sử dụng selector như group=web-servers, role=db để áp dụng quy tắc riêng cho từng loại máy chủ.
Chính sách Theo Môi trường: Sử dụng selector như env=production, env=staging để phân tách quy tắc giữa các môi trường.
Chính sách Bảo mật Ưu tiên cao: Sử dụng order thấp (ví dụ: 10, 20) và action deny để chặn các truy cập không mong muốn (ví dụ: chặn IP độc hại, chặn truy cập SSH từ internet).
Chính sách Tạm thời/Lập lịch: Sử dụng tính năng lập lịch (scheduling) để kích hoạt/vô hiệu hóa chính sách vào những thời điểm cụ thể (xem mục Lập lịch chính sách).

5.4 Selector và cách sử dụng¶

Selector là chìa khóa để áp dụng chính sách đúng chỗ. Cú pháp bao gồm:

key=value: Khớp máy chủ có nhãn key bằng value.
key!=value: Khớp máy chủ có nhãn key khác value hoặc không có nhãn key.
key in (value1, value2): Khớp nếu nhãn key là value1 hoặc value2.
key notin (value1, value2): Khớp nếu nhãn key không phải value1 hoặc value2.
key: Khớp nếu máy chủ có nhãn key (bất kỳ giá trị nào).
!key: Khớp nếu máy chủ không có nhãn key.
*: Khớp tất cả máy chủ.
Kết hợp nhiều điều kiện bằng dấu phẩy , (tương đương AND). Ví dụ: env=production,role=web.

Ví dụ Selector trong quy tắc (From/To):

from: selector: "internet": Lưu lượng từ Zone internet.
from: selector: "group=monitoring": Lưu lượng từ các máy chủ thuộc nhóm monitoring.
to: cidr: "10.0.0.0/8": Lưu lượng đến mạng nội bộ 10.0.0.0/8.

5.5 Thứ tự ưu tiên và xử lý xung đột¶

Khi một máy chủ khớp với nhiều chính sách:

Các chính sách được sắp xếp theo order từ thấp đến cao (ưu tiên cao đến thấp).
Các quy tắc (Ingress/Egress) bên trong tất cả các chính sách khớp được gộp lại theo thứ tự ưu tiên của chính sách.
Đối với một kết nối cụ thể, Agent sẽ duyệt qua danh sách quy tắc đã gộp. Quy tắc đầu tiên khớp với kết nối đó sẽ được áp dụng (allow hoặc deny).
Nếu không có quy tắc nào khớp, hành động mặc định là deny.

Mẹo:

Đặt order thấp cho các quy tắc deny quan trọng (ví dụ: chặn IP xấu).
Đặt order cao cho các chính sách mặc định (ví dụ: allow ICMP).
Sử dụng các khoảng order (10, 20, 100, 110) để dễ dàng chèn chính sách mới vào giữa.

5.6 Lập lịch chính sách (Scheduling)¶

Cho phép kích hoạt/vô hiệu hóa chính sách theo thời gian.

Tạo/Cập nhật chính sách với lịch trình: Thêm block schedulers vào định nghĩa YAML hoặc dùng các tham số --scheduler-* khi tạo/cập nhật bằng CLI.

# Ví dụ trong YAML
schedulers:
  - name: "weekend-maintenance"
    startTime: "01:00" # Giờ địa phương của API Server
    endTime: "05:00"
    daysOfWeek: ["Saturday", "Sunday"]

# Ví dụ CLI khi tạo
ocnfwctl policy create ... --scheduler-name "maint" --scheduler-start "01:00" ...

Xem lịch trình: ocnfwctl policy schedulers --id <policy_id>
Cập nhật lịch trình: ocnfwctl policy update-scheduler ...
Xóa lịch trình: ocnfwctl policy delete-scheduler ...

Khi chính sách được lập lịch, nó chỉ có hiệu lực trong khoảng thời gian được chỉ định.

5.7 Quản lý chính sách qua API¶

Sử dụng API để tự động hóa việc quản lý chính sách. Tham khảo system-policy.md hoặc tài liệu API cho các endpoint như:

GET /api/v1/policies
POST /api/v1/policies
GET /api/v1/policies/{id}
PUT /api/v1/policies/{id}
DELETE /api/v1/policies/{id}
Các API liên quan đến rules và schedulers.

5.8 Kiểm tra và xác thực chính sách¶

Trước khi áp dụng vào môi trường sản xuất, hãy kiểm tra kỹ lưỡng:

Kiểm tra cú pháp YAML: Đảm bảo file YAML hợp lệ.

Kiểm tra tính hợp lệ của chính sách:

ocnfwctl policy validate -f <policy_file.yaml>

Kiểm tra máy chủ nào sẽ khớp với selector:

ocnfwctl policy check-match --id <policy_id_or_name>
# Hoặc kiểm tra với selector tùy ý
ocnfwctl policy check-match --selector "env=production,role!=db"

Kiểm tra tác động lên kết nối cụ thể: (Rất hữu ích để debug)

# Kiểm tra kết nối từ 1.2.3.4 đến 10.0.0.5 cổng 80/tcp sẽ bị xử lý thế nào
ocnfwctl policy check-connection --src-ip 1.2.3.4 --dst-ip 10.0.0.5 --dst-port 80 --protocol tcp

Mô phỏng áp dụng (Simulate): (Nếu được hỗ trợ) Xem trước những thay đổi mà chính sách mới sẽ gây ra mà không thực sự áp dụng.
```
ocnfwctl policy simulate -f <new_policy.yaml>
```

5.9 Ví dụ chính sách phổ biến¶

Tham khảo các ví dụ trong system-policy.md cho các kịch bản như:

Máy chủ Web (cho phép HTTP/S vào, cho phép ra DB/Cache).
Máy chủ Database (chỉ cho phép vào từ App/Web, cho phép ra Backup).
Chính sách Bảo mật cơ bản (cho phép SSH từ admin, chặn IP xấu).
Phân tách môi trường (chặn giao tiếp giữa Production và Staging).

6. Sao lưu và Phục hồi¶

Đảm bảo an toàn dữ liệu và khả năng khôi phục hệ thống là cực kỳ quan trọng.

6.1 Tầm quan trọng của sao lưu/phục hồi¶

Việc sao lưu và phục hồi đúng cách giúp bạn:

Phòng ngừa mất dữ liệu cấu hình (users, policies, servers, zones) do lỗi phần cứng/phần mềm hoặc lỗi người dùng.
Tạo điểm khôi phục an toàn trước khi thực hiện các thay đổi lớn.
Di chuyển dữ liệu giữa các môi trường.
Đáp ứng các yêu cầu về tuân thủ và lưu trữ.

6.2 Chiến lược sao lưu¶

Nên áp dụng chiến lược đa lớp:

Sao lưu Cơ sở dữ liệu MongoDB: Chứa tất cả dữ liệu cốt lõi. Đây là phần quan trọng nhất.
Xuất cấu hình OCN Firewall: Sử dụng ocnfwctl export để lưu các đối tượng chính (policies, zones, system config) dưới dạng file YAML/JSON có thể đọc và import lại được.
Sao lưu Tệp cấu hình: Lưu các tệp cấu hình của API Server (.env, docker-compose.yaml, config.env) và Agent (agent.env).

6.3 Sao lưu Cơ sở dữ liệu MongoDB¶

Sử dụng công cụ mongodump của MongoDB.

Sao lưu toàn bộ database firewall:

# Sao lưu có nén (khuyến nghị)
mongodump --uri "mongodb://firewall_user:YourPassword@<MONGODB_HOST>:27017/firewall?authSource=firewall" \
          --out /path/to/backup/mongodb/$(date +"%Y-%m-%d_%H-%M-%S") \
          --gzip

# Sao lưu không nén
mongodump --uri "mongodb://firewall_user:YourPassword@<MONGODB_HOST>:27017/firewall?authSource=firewall" \
          --out /path/to/backup/mongodb/$(date +"%Y-%m-%d_%H-%M-%S")

# Lưu ý: Thay YourPassword, <MONGODB_HOST> và authSource nếu cần.
# Nếu dùng Replica Set, URI sẽ khác (xem mục HA).

Sao lưu collection cụ thể: (Ít phổ biến hơn cho backup tổng thể)

mongodump --uri "..." --collection policies --out /path/to/backup/policies_only --gzip

6.4 Xuất cấu hình OCN Firewall¶

Sử dụng ocnfwctl ... export để tạo các bản sao lưu cấu hình dưới dạng file. Các file này hữu ích cho việc xem lại cấu hình hoặc import vào hệ thống khác/sau khi cài đặt lại.

Xuất tất cả chính sách:

ocnfwctl policy export --output-dir /path/to/backup/configs/policies/$(date +"%Y-%m-%d")

Xuất tất cả zone:

ocnfwctl zone export --output-dir /path/to/backup/configs/zones/$(date +"%Y-%m-%d")

Xuất cấu hình hệ thống:

ocnfwctl system export --output-file /path/to/backup/configs/system-config-$(date +"%Y-%m-%d").yaml

Script sao lưu cấu hình: Bạn có thể tạo script để tự động export tất cả và nén lại (xem ví dụ script trong backup-restore.md).

6.5 Sao lưu Tệp cấu hình¶

Đừng quên sao lưu các tệp cấu hình quan trọng:

API Server:
- Docker: /opt/ocn-firewall/.env, /opt/ocn-firewall/docker-compose.yaml
- Manual: /etc/ocn-firewall/config.env, /etc/systemd/system/firewalld.service
Agent:
- Linux: /etc/ocn-firewall/agent.env, /etc/systemd/system/ocn-firewall-agent.service
- Windows: C:\Program Files\OCN Firewall\agent.env, (cấu hình dịch vụ trong Registry/SC)

6.6 Tự động hóa sao lưu¶

Sử dụng cron (Linux) hoặc Task Scheduler (Windows) để tự động chạy các lệnh sao lưu định kỳ.

Ví dụ Cron Job (Linux) sao lưu MongoDB hàng ngày lúc 2 giờ sáng:

# /etc/cron.d/ocn-firewall-backup
0 2 * * * root mongodump --uri "mongodb://..." --out /backup/mongodb/$(date +"\%Y-\%m-\%d") --gzip >> /var/log/ocn-firewall-backup.log 2>&1

Script sao lưu tự động: Xem xét việc tạo một script backup.sh toàn diện (như ví dụ trong backup-restore.md) để thực hiện sao lưu DB, export cấu hình, nén, mã hóa (tùy chọn), xác thực, dọn dẹp bản cũ và gửi thông báo.

6.7 Phục hồi dữ liệu¶

Phục hồi Cơ sở dữ liệu MongoDB¶

Sử dụng mongorestore. Cảnh báo: mongorestore thường xóa dữ liệu hiện có trong collection trước khi phục hồi. Hãy cẩn thận khi thực hiện trên môi trường sản xuất. Cân nhắc dừng API Server trước khi restore.

Phục hồi toàn bộ database từ bản sao lưu nén:

mongorestore --uri "mongodb://firewall_user:YourPassword@<MONGODB_HOST>:27017/firewall?authSource=firewall" \
             --gzip /path/to/backup/mongodb/<backup_date_dir>/firewall
# Lưu ý: Trỏ đến thư mục chứa dump của database 'firewall' bên trong thư mục backup.

Phục hồi toàn bộ database từ bản sao lưu không nén:

mongorestore --uri "..." /path/to/backup/mongodb/<backup_date_dir>/firewall

Phục hồi collection cụ thể: (Ví dụ: chỉ phục hồi policies)

mongorestore --uri "..." --collection policies --gzip /path/to/backup/mongodb/<backup_date_dir>/firewall/policies.bson.gz

Phục hồi Cấu hình từ File Export¶

Sử dụng ocnfwctl ... apply để nhập lại cấu hình từ các file YAML/JSON đã export.

Nhập một chính sách:

ocnfwctl policy apply -f /path/to/backup/configs/policies/<date>/policy-name.yaml

Nhập nhiều chính sách từ thư mục:

ocnfwctl policy apply -d /path/to/backup/configs/policies/<date>/

Nhập zone: (Tương tự với ocnfwctl zone apply)

ocnfwctl zone apply -f /path/to/backup/configs/zones/<date>/zone-name.yaml
ocnfwctl zone apply -d /path/to/backup/configs/zones/<date>/

Nhập cấu hình hệ thống:

ocnfwctl system apply -f /path/to/backup/configs/system-config-<date>.yaml

Phục hồi Tệp cấu hình¶

Sao chép các tệp cấu hình đã sao lưu (.env, docker-compose.yaml, agent.env, etc.) trở lại vị trí ban đầu của chúng. Sau đó, khởi động lại các dịch vụ liên quan (API Server, Agent) để áp dụng thay đổi.

Ví dụ phục hồi API Server Docker:

cp /path/to/backup/api-server-env.<date> /opt/ocn-firewall/.env
cp /path/to/backup/docker-compose.<date>.yaml /opt/ocn-firewall/docker-compose.yaml
cd /opt/ocn-firewall
docker-compose down # Dừng container hiện tại
docker-compose up -d # Khởi động lại với cấu hình mới

Ví dụ phục hồi Agent Linux:

cp /path/to/backup/agent-config.<date>.env /etc/ocn-firewall/agent.env
# Cập nhật file service nếu cần
systemctl restart ocn-firewall-agent

6.8 Quy trình phục hồi đầy đủ¶

Trong trường hợp thảm họa cần khôi phục toàn bộ hệ thống:

Cài đặt lại hệ điều hành, Docker (nếu dùng), MongoDB (nếu cần) trên các máy chủ mới/đã được làm sạch.
Phục hồi cơ sở dữ liệu MongoDB từ bản sao lưu gần nhất và tốt nhất (mongorestore).
Phục hồi các tệp cấu hình của API Server (.env, docker-compose.yaml hoặc config.env, firewalld.service).
Khởi động lại dịch vụ API Server.
Kiểm tra API Server đã hoạt động và dữ liệu đã được phục hồi (đăng nhập, liệt kê policies/servers).
Cài đặt lại Agent trên các máy chủ client (nếu cần).
Phục hồi tệp cấu hình Agent (agent.env, service file).
Khởi động lại dịch vụ Agent trên các máy chủ client.
Kiểm tra trạng thái kết nối của Agent và việc áp dụng chính sách.

Xem xét script phục hồi mẫu trong backup-restore.md để tự động hóa một phần quy trình này.

6.9 Kiểm thử và xác thực phục hồi¶

Không bao giờ cho rằng bản sao lưu của bạn hoạt động tốt nếu chưa kiểm tra phục hồi. Định kỳ (ví dụ: hàng quý) thực hiện quy trình phục hồi trên một môi trường thử nghiệm riêng biệt:

Dựng một môi trường OCN Firewall thử nghiệm (có thể thu nhỏ).
Lấy một bản sao lưu gần đây từ môi trường sản xuất.
Thực hiện quy trình phục hồi đầy đủ trên môi trường thử nghiệm.
Xác thực dữ liệu sau phục hồi:
- Đăng nhập thành công (ocnfwctl login).
- Kiểm tra số lượng/nội dung policies, zones, servers (ocnfwctl policy list, zone list, server list).
- Kết nối một Agent thử nghiệm và xem nó có nhận chính sách không.
- Kiểm tra API health (curl .../health).

6.10 Chiến lược lưu giữ bản sao lưu¶

Xác định chính sách lưu giữ phù hợp với yêu cầu của tổ chức (ví dụ: mô hình GFS - Grandfather-Father-Son):

Hàng ngày (Daily): Lưu giữ 7-14 ngày gần nhất.
Hàng tuần (Weekly): Lưu giữ 4-8 tuần gần nhất (thường là bản sao lưu cuối tuần).
Hàng tháng (Monthly): Lưu giữ 6-12 tháng gần nhất (thường là bản sao lưu cuối tháng).
Hàng năm (Yearly): Lưu giữ 1-n năm (tùy yêu cầu tuân thủ).

Sử dụng script để tự động xóa các bản sao lưu cũ không còn cần thiết (ví dụ: dùng find ... -mtime +N -delete như trong backup-restore.md).

6.11 Sao lưu/Phục hồi trong môi trường HA¶

Sao lưu MongoDB Replica Set: mongodump có thể kết nối đến Replica Set URI. Nó thường sẽ đọc từ một secondary node để giảm tải cho primary.

mongodump --uri "mongodb://firewall_user:YourPassword@mongo1:27017,mongo2:27017,mongo3:27017/firewall?replicaSet=ocnfirewall&authSource=firewall" --out ... --gzip

Phục hồi vào MongoDB Replica Set:
1. Quan trọng: Dừng tất cả các instance API Server để tránh ghi dữ liệu trong quá trình restore.
2. Thực hiện mongorestore vào Primary node của Replica Set (sử dụng URI của Replica Set). Dữ liệu sẽ tự động được nhân bản sang các secondary nodes.
3. Khởi động lại các instance API Server.

6.12 Khuyến nghị bảo mật cho bản sao lưu¶

Mã hóa: Mã hóa các tệp sao lưu (đặc biệt là dump MongoDB) bằng GPG hoặc các công cụ mã hóa khác trước khi lưu trữ hoặc chuyển đi nơi khác.
```
gpg --encrypt --recipient your_admin_email@example.com backup_file.tar.gz
```
Lưu trữ Offsite/Offline: Lưu trữ ít nhất một bản sao lưu ở một vị trí vật lý hoặc mạng khác với hệ thống sản xuất (ví dụ: cloud storage, máy chủ backup riêng, băng từ).
Hạn chế quyền truy cập: Đặt quyền truy cập chặt chẽ trên thư mục chứa bản sao lưu và các tệp sao lưu (ví dụ: chmod 600). Chỉ cho phép người dùng/nhóm quản trị được ủy quyền truy cập.
Kiểm tra định kỳ: Đảm bảo quy trình kiểm tra phục hồi được thực hiện thường xuyên.

7. Giám sát và Bảo trì¶

Để đảm bảo OCN Firewall hoạt động ổn định và hiệu quả, cần thực hiện giám sát và bảo trì thường xuyên.

7.1 Kiểm tra sức khỏe hệ thống¶

API Server Health Check: Thường xuyên kiểm tra endpoint /api/v1/health. Tích hợp vào hệ thống giám sát của bạn (Nagios, Zabbix, Prometheus) để cảnh báo nếu API Server không phản hồi hoặc trạng thái không tốt.
MongoDB Status: Giám sát trạng thái của MongoDB (hoặc Replica Set), kiểm tra tài nguyên (CPU, RAM, Disk I/O, Disk Space).
API Server Resources: Giám sát tài nguyên (CPU, RAM, Network) của máy chủ chạy API Server.

7.2 Giám sát kết nối Agent¶

Sử dụng ocnfwctl server list --status offline để tìm các Agent đang mất kết nối.
Sử dụng ocnfwctl server list --columns id,hostname,lastHeartbeat để xem thời điểm Agent kết nối lần cuối.
Thiết lập cảnh báo nếu lastHeartbeat quá cũ so với cấu hình HEARTBEAT_OFFLINE_THRESHOLD trên API Server (ví dụ: Agent offline quá 5 phút).
Giám sát log của Agent trên các máy chủ client để phát hiện lỗi kết nối hoặc áp dụng chính sách.

7.3 Xem xét nhật ký hệ thống¶

API Server Logs: Kiểm tra log của API Server (qua docker logs hoặc journalctl) để tìm lỗi, cảnh báo hoặc các hoạt động bất thường.
Audit Logs (ocnfwctl logs): Định kỳ xem xét nhật ký hoạt động (ocnfwctl logs list) để theo dõi các thay đổi cấu hình, đăng nhập người dùng, v.v. Lọc theo resource (user, policy, server) hoặc resource-id.
Agent Logs: Kiểm tra log của Agent trên các máy chủ client khi khắc phục sự cố.

7.4 Kiểm tra trạng thái áp dụng chính sách¶

Sử dụng ocnfwctl server policy-status --id <server_id> để xem liệu Agent có đang áp dụng đúng phiên bản chính sách từ API Server hay không.
Kiểm tra thực tế các quy tắc tường lửa trên máy chủ client (iptables -L, nft list ruleset, netsh advfirewall show rule name=all) để đảm bảo chúng khớp với chính sách mong đợi.

7.5 Cập nhật hệ thống¶

Cập nhật API Server và Agent: Theo dõi các bản phát hành mới của OCN Firewall và lên kế hoạch cập nhật để nhận các tính năng mới, bản vá lỗi và cải tiến bảo mật. Thực hiện cập nhật trên môi trường thử nghiệm trước.
Cập nhật MongoDB: Cập nhật MongoDB theo khuyến nghị của nhà cung cấp.
Cập nhật Hệ điều hành và Dependencies: Giữ cho hệ điều hành và các phần mềm phụ thuộc (Docker, OS libraries) được cập nhật bản vá bảo mật.

8. Bảo mật Nâng cao¶

Ngoài các cấu hình cơ bản, hãy xem xét các biện pháp bảo mật sau:

8.1 Bảo vệ API Server¶

Sử dụng HTTPS: Cấu hình Load Balancer (Nginx, HAProxy) hoặc reverse proxy phía trước API Server để cung cấp mã hóa SSL/TLS cho tất cả các kết nối đến API (từ CLI, Agent, Dashboard). Tham khảo cấu hình Nginx mẫu trong deployment.md để bật SSL.
Hạn chế Truy cập Mạng: Cấu hình tường lửa hệ thống (ufw, firewalld) trên máy chủ API Server hoặc cấu hình trong Load Balancer để chỉ cho phép truy cập vào cổng API (ví dụ: 80/443) từ các dải IP tin cậy (mạng quản trị, mạng của Agent).
Giới hạn Tỷ lệ Truy cập (Rate Limiting): Cấu hình rate limiting trên Load Balancer để chống lại các cuộc tấn công brute-force hoặc DoS vào API đăng nhập.

8.2 Bảo vệ MongoDB¶

Xác thực Mạnh: Luôn bật xác thực (security.authorization: enabled) và sử dụng mật khẩu mạnh cho người dùng MongoDB.
Hạn chế Truy cập Mạng: Cấu hình tường lửa hệ thống trên(các) máy chủ MongoDB để chỉ cho phép kết nối đến cổng 27017 từ địa chỉ IP của(các) API Server instance. Không nên mở cổng MongoDB ra mạng công cộng hoặc các mạng không cần thiết.
Sử dụng TLS/SSL (Tùy chọn): Cấu hình MongoDB và API Server để sử dụng kết nối TLS/SSL giữa chúng, đảm bảo dữ liệu được mã hóa khi truyền trên mạng nội bộ.

8.3 Thực thi chính sách mật khẩu và 2FA¶

Đảm bảo chính sách mật khẩu đủ mạnh được áp dụng.
Khuyến khích hoặc bắt buộc người dùng (đặc biệt là admin và operator) bật 2FA.

8.4 Xem xét nhật ký kiểm toán (Audit Logs)¶

Thường xuyên xem xét nhật ký hoạt động (ocnfwctl logs list) để phát hiện các hành động đáng ngờ hoặc trái phép, chẳng hạn như thay đổi chính sách không mong muốn, tạo người dùng lạ, hoặc các lần đăng nhập thất bại liên tục.

9. Khắc phục sự cố (Troubleshooting)¶

Phần này cung cấp hướng dẫn xử lý một số sự cố phổ biến.

9.1 Sự cố với API Server¶

Triệu chứng: CLI không kết nối được, Agent báo lỗi kết nối, Dashboard không truy cập được.
Kiểm tra:
1. Trạng thái dịch vụ/container: systemctl status firewalld hoặc docker ps, docker logs ocn-firewalld.
2. Log của API Server: Tìm thông báo lỗi chi tiết.
3. Kết nối MongoDB: API Server có kết nối được tới MongoDB không? Kiểm tra cấu hình DB_URI. Thử kết nối thủ công tới MongoDB từ máy chủ API Server.
4. Tài nguyên máy chủ: Kiểm tra CPU, RAM, Disk space trên máy chủ API Server và MongoDB.
5. Kết nối mạng: Firewall hệ thống có chặn cổng 8080 không?

9.2 Sự cố với Agent¶

Triệu chứng: Máy chủ hiển thị offline trên Dashboard/CLI, chính sách không được áp dụng/cập nhật.
Kiểm tra:
1. Trạng thái dịch vụ Agent: systemctl status ocn-firewall-agent (Linux) hoặc kiểm tra dịch vụ “OCNFirewallAgent” (Windows).
2. Log của Agent: Kiểm tra log (journalctl -u ocn-firewall-agent hoặc Event Viewer) để tìm lỗi kết nối, lỗi token, lỗi áp dụng quy tắc.
3. Kết nối mạng: Agent có thể ping và kết nối đến địa chỉ và cổng của API Server (hoặc Load Balancer) không? (curl -v http://<API_SERVER_ADDRESS>:8080/api/v1/health). Firewall trên đường đi có chặn không?
4. Token xác thực: Token (AGENT_TOKEN trong cấu hình) có còn hợp lệ không? Token có bị thu hồi trên API Server không?
5. Quyền hạn: Agent có đủ quyền (root/Administrator) để sửa đổi quy tắc tường lửa hệ thống không?
6. Xung đột: Có phần mềm nào khác đang quản lý iptables/Windows Firewall gây xung đột không?

9.3 Sự cố đăng nhập người dùng¶

Triệu chứng: Lỗi “Invalid credentials”, không thể đăng nhập.
Kiểm tra:
1. Username/Password: Đảm bảo nhập đúng. Phân biệt chữ hoa/thường.
2. Tài khoản bị khóa/vô hiệu hóa: Nhờ admin kiểm tra trạng thái tài khoản (ocnfwctl user get --username ...).
3. 2FA: Nếu đã bật 2FA, đảm bảo nhập đúng mã TOTP từ ứng dụng Authenticator. Đồng hồ trên thiết bị và máy chủ cần được đồng bộ. Nếu mất thiết bị, nhờ admin reset 2FA.
4. API Server: API Server có đang hoạt động không?

9.4 Sự cố áp dụng chính sách¶

Triệu chứng: Lưu lượng bị chặn/cho phép không đúng như mong đợi.
Kiểm tra:
1. Selector Chính sách: Chính sách bạn mong đợi có selector khớp với nhãn/nhóm của máy chủ không? (ocnfwctl policy check-match --id <policy_id> --server-id <server_id>).
2. Thứ tự ưu tiên (Order): Có chính sách nào khác với order thấp hơn (ưu tiên cao hơn) đang ghi đè lên quy tắc bạn mong đợi không? (ocnfwctl policy list --selector "<server_selector>" --columns id,name,order).
3. Nội dung Quy tắc: Quy tắc (From/To, Ports, Protocol, Action) có đúng không?
4. Trạng thái Đồng bộ Agent: Agent có đang chạy phiên bản chính sách mới nhất không? (ocnfwctl server policy-status --id <server_id>). Thử buộc đồng bộ (ocnfwctl server sync-policies --id <server_id>).
5. Kiểm tra kết nối cụ thể: Sử dụng ocnfwctl policy check-connection ... để xem OCN Firewall dự đoán sẽ xử lý kết nối đó như thế nào.
6. Kiểm tra Quy tắc Thực tế: Xem quy tắc tường lửa thực tế trên máy chủ client (iptables -L -n -v, nft list ruleset) để xem Agent đã áp dụng gì.

9.5 Kiểm tra log¶

Log là công cụ quan trọng nhất để chẩn đoán sự cố. Biết vị trí và cách đọc log của từng thành phần:

API Server (Docker): docker logs ocn-firewalld
API Server (Manual): sudo journalctl -u firewalld -f
Agent (Linux): sudo journalctl -u ocn-firewall-agent -f
Agent (Windows): Event Viewer -> Windows Logs -> Application (Filter by Source “OCNFirewallAgent”)
OCN Firewall Audit Logs: ocnfwctl logs list ...

10. Phụ lục¶

10.1 Thuật ngữ¶

API Server (Firewalld): Thành phần trung tâm quản lý.
Agent: Chương trình chạy trên máy chủ client, nhận và áp dụng chính sách.
Policy: Tập hợp các quy tắc tường lửa và điều kiện áp dụng.
Rule: Một quy định cụ thể trong Policy (ví dụ: cho phép TCP/80 từ internet).
Selector: Biểu thức logic (dựa trên nhãn/nhóm) để xác định máy chủ hoặc nguồn/đích lưu lượng.
Label: Cặp key-value tùy ý gán cho máy chủ hoặc chính sách để phân loại.
Group: Một thuộc tính chính để nhóm các máy chủ có chức năng tương tự.
Zone: Một tập hợp các dải CIDR được định nghĩa trước (ví dụ: internet, private).
Ingress: Lưu lượng đi vào máy chủ.
Egress: Lưu lượng đi ra từ máy chủ.
Order: Số nguyên xác định thứ tự ưu tiên áp dụng chính sách.
CLI (ocnfwctl): Công cụ giao diện dòng lệnh.
Dashboard: Giao diện quản lý web.
MongoDB: Cơ sở dữ liệu lưu trữ cấu hình.
mongodump/mongorestore: Công cụ sao lưu/phục hồi MongoDB.
HA (High Availability): Tính sẵn sàng cao.
Replica Set: Cụm MongoDB HA.
Load Balancer: Bộ cân bằng tải, phân phối kết nối đến nhiều API Server.
2FA/TOTP: Xác thực hai yếu tố / Mật khẩu dùng một lần dựa trên thời gian.