運維安全06 - 服務安全

云計算服務安全

在當今數字化時代，各種服務（如網絡應用、云計算平臺、數據庫系統等）已成為我們日常生活和工作中不可或缺的一部分。

然而，隨著服務的廣泛應用，其安全性問題也日益凸顯。

一、服務安全

服務安全是一系列技術和管理措施的集合，旨在保障服務系統的正常運行和數據的安全。

它涵蓋了從物理層面到軟件層面的多個方面，包括但不限于：

訪問控制：通過身份驗證和授權機制，確保只有合法用戶或進程能夠訪問特定的服務資源。
數據加密：對傳輸和存儲的數據進行加密處理，防止數據在傳輸過程中被竊取或篡改。
安全審計：記錄和分析系統操作日志，及時發現并應對潛在的安全威脅。
漏洞管理：定期檢查和修復系統中的安全漏洞，減少被攻擊的風險。
災難恢復：制定應急響應計劃和備份策略，確保在發生安全事件時能夠迅速恢復服務。

服務安全是指保護這些服務免受未經授權的訪問、數據泄露、惡意攻擊等威脅，確保服務的可用性、完整性和保密性。

1.1 SELinux

SELinux（Security-Enhanced Linux）是 Linux 內核的一個安全模塊，提供 強制訪問控制（MAC）機制 ，通過預定義的安全策略來限制進程和資源之間的訪問行為。

在當今數字化時代，服務如網絡應用、云計算平臺和數據庫系統等已經成為日常生活和工作中不可或缺的一部分。隨著這些技術的廣泛應用，其安全性問題也日益凸顯。

為了確保這些服務的安全性，采用多層次的安全策略變得尤為重要。

將云計算平臺的安全需求與SELinux（Security-Enhanced Linux）所提供的強大安全功能相結合，以增強整體的服務安全性。

selinux與云平臺的結合

1. 云計算環境中的多租戶挑戰

在云計算環境中，多租戶架構是常見模式，這意味著多個用戶或組織共享相同的物理資源，但各自擁有獨立的虛擬環境。這種設置帶來了獨特的安全挑戰，因為必須確保一個租戶的操作不會影響到另一個租戶的數據安全性和隱私。通過實施SELinux，可以基于細粒度的訪問控制來隔離不同租戶的工作負載，從而有效地防止潛在的安全威脅跨越租戶邊界。

2. 強化數據保護

無論是存儲在云中的敏感數據還是通過網絡傳輸的信息，都需要得到妥善保護。SELinux通過其靈活且強大的強制訪問控制（MAC）機制，能夠為文件、目錄以及網絡端口定義詳細的訪問規則。這意味著即使是操作系統級別的漏洞被利用，攻擊者也無法輕易獲取對關鍵數據的訪問權限，極大地增強了數據的安全性。

3. 提升應用層防護

除了基礎架構層面的安全措施外，針對運行于云端的應用程序本身也需要采取額外的安全防護措施。借助SELinux，開發者可以為特定應用程序定制安全策略，限制它們只能執行預期的行為，減少因代碼缺陷導致的安全風險。這對于維護云上部署的應用程序的安全性至關重要。

4. 應對新興威脅

隨著技術的發展，新的安全威脅不斷涌現。SELinux提供了一種動態調整安全策略的能力，允許管理員快速響應新出現的威脅。這使得無論是在公有云、私有云還是混合云環境中，都能夠保持高水平的安全態勢，保障業務連續性和數據完整性。

1.2 訪問控制

訪問控制是計算機安全領域的一個核心概念，旨在保護系統資源免受未經授權的訪問。

主要存在兩種類型的訪問控制模型：自主訪問控制（DAC）和強制訪問控制（MAC）。

自主訪問控制（DAC）

自主性：在DAC中，資源的所有者有權決定誰可以訪問這些資源以及訪問的權限級別。
基于用戶身份驗證：DAC依賴于用戶的身份來分配權限，通常通過文件或目錄的讀、寫、執行權限體現出來。
靈活性高：由于權限是由資源所有者自行設置的，因此DAC提供了很高的靈活性，允許細粒度的權限管理。

在一個Linux系統中，有一個名為/home/user1/project的目錄，屬于用戶user1。

用戶user1可以通過命令chmod 750 /home/user1/project設置該目錄的權限為：

rwx（讀、寫、執行）對于所有者user1
r-x（讀、執行）對于同組用戶
---（無權限）對于其他用戶

這樣，只有user1和他的組成員能夠訪問這個項目目錄，而其他人則無法訪問。

優缺點分析：

優點：易于使用和配置，適合小規模環境。
缺點：安全性較低，因為權限是由普通用戶設置的，容易發生錯誤配置導致的安全漏洞。

強制訪問控制（MAC）

強制性：MAC是一種更嚴格的訪問控制形式，它不依賴于用戶的個人決策，而是根據預定義的安全策略來控制訪問權限。
基于安全標簽：每個主體（如用戶或進程）和客體（如文件或網絡端口）都被賦予一個安0全標簽，系統根據這些標簽和安全策略決定是否允許訪問。
適用于高安全性需求場景：MAC通常用于需要高度安全保障的環境。

管理員配置了一個策略，規定Web服務器只能訪問特定的網頁內容目錄，并且不能訪問數據庫文件。

即使以root用戶身份運行，如果嘗試訪問未授權的資源，也將被拒絕。

在SELinux中，可以通過以下命令查看當前目錄的安全上下文：

ls -Z /var/www/html

然后，管理員可以根據安全需求調整相關文件的安全標簽，確保它們只被適當的進程訪問。

優缺點分析：

優點：提供了更高的安全性和更細粒度的控制，防止了權限濫用。
缺點：配置復雜，不適合對安全性要求不高的普通用戶。

1.2.1核心概念

名稱	含義
主體（Subject）	如用戶、進程
客體（Object）	文件、目錄、端口等系統資源
安全上下文（Security Context）	格式：`user:role:type[:level]`，標識主體或客體的身份
策略（Policy）	控制誰可以對哪些資源執行哪些操作

主體（Subject）

主體是指 發起操作的一方 ，通常是運行中的 進程或用戶 。它是請求訪問資源的“行為者”。

當在終端中執行 cat /etc/passwd 命令時，這個命令對應的 bash 進程 就是主體。
Web 服務器（如 Nginx 或 Apache）運行的 nginx 進程 是一個典型的主體。
SSH 登錄的用戶通過 sshd 進程 發起操作，此時該進程就是主體。

主體 = “誰” 在做某件事（例如讀取、寫入、執行）。

客體（Object）

客體是 被訪問的目標資源 ，可以是文件、目錄、網絡端口、設備等系統中的任何對象。

/etc/shadow 文件是一個客體，它保存了系統的密碼信息。
/var/www/html/index.html 是一個網頁文件，也是客體。
TCP 端口 80（HTTP）也是一個客體，Nginx 需要綁定它來提供服務。

客體 = “什么” 被訪問或操作。

安全上下文（Security Context）

安全上下文是 SELinux 給每個 主體和客體 打上的“身份標簽”，用于標識它們屬于哪個用戶、角色、類型和安全級別。

安全上下文 = “是誰？能做什么？” 的身份標簽。

user:role:type[:level]

字段	說明
`user`	SELinux 用戶身份（不同于 Linux 操作系統用戶）
`role`	角色，定義用戶可以扮演哪些角色（如 sysadm_r 表示系統管理員角色）
`type`	類型，是最關鍵的部分，決定了訪問權限
`level`	可選字段，用于多級安全策略（MLS），表示敏感級別（如 s0, s1:c0.c2）

ls -Z /etc/passwd
?
system_u:object_r:shadow_t:s0 /etc/passwd

system_u：SELinux 用戶為系統用戶
object_r：角色為對象角色
shadow_t：類型為 shadow 類型，只允許特定進程訪問
s0：安全級別

在 SELinux 中，用戶身份（User Identity）是安全上下文的一部分，用于標識系統中的主體（如進程、用戶）。

盡管它被稱為“用戶”，但它與傳統的 Linux 系統用戶不同。

SELinux 用戶身份主要用于定義哪些角色（Roles）和類型（Types）可以被分配給特定的用戶或進程。

SELinux 用戶描述
system_u 用于系統進程和服務，默認適用于大多數后臺服務。
root 特殊的 SELinux 用戶，通常用于超級用戶操作。
user_u 普通非特權用戶的默認 SELinux 用戶身份。
staff_u 提供給需要額外權限的管理員使用。

配置一個 Web 服務器（比如 Nginx），并且希望確保其運行在一個受限制的環境中：

系統服務使用system_u` ：這里的system_u` 表明這是一個系統級別的進程，它只能承擔系統級別的角色，并且只能訪問與其類型匹配的資源。

普通用戶使用user_u` ：這意味著他們不能訪問那些只允許system_u` 或其他特定類型訪問的資源。

SELinux 用戶	描述
`system_u`	用于系統進程和服務，默認適用于大多數后臺服務。
`root`	特殊的 SELinux 用戶，通常用于超級用戶操作。
`user_u`	普通非特權用戶的默認 SELinux 用戶身份。
`staff_u`	提供給需要額外權限的管理員使用。

SELinux 使用角色來實現 用戶到類型的映射 ，也就是說：

某個用戶（如 user_u）只能進入某些角色（如 user_r）

每個角色又允許使用某些類型（domain），也就是進程可以運行的上下文

通過定義不同的角色，SELinux 實現了 基于角色的訪問控制（RBAC） ，不同角色有不同的權限范圍。

角色名描述
system_r 系統服務角色，適用于后臺守護進程（如 Nginx、Apache）
object_r 對象角色，適用于文件、目錄等資源對象
user_r 普通用戶角色，限制較為嚴格
sysadm_r 系統管理員角色，具有更高的權限，適合執行系統管理任務
staff_r 高級用戶角色，介于普通用戶和管理員之間
unconfined_r 非受限角色，在寬松模式下使用

角色名	描述
`system_r`	系統服務角色，適用于后臺守護進程（如 Nginx、Apache）
`object_r`	對象角色，適用于文件、目錄等資源對象
`user_r`	普通用戶角色，限制較為嚴格
`sysadm_r`	系統管理員角色，具有更高的權限，適合執行系統管理任務
`staff_r`	高級用戶角色，介于普通用戶和管理員之間
`unconfined_r`	非受限角色，在寬松模式下使用

如果一個普通用戶的安全上下文是：
user_u:user_r:user_t:s0
那么他只能運行屬于 user_t 類型的程序，并且不能執行需要更高權限的操作，比如啟動網絡服務或訪問 /etc/shadow 文件，即使 Linux 權限允許。

這是因為 SELinux 策略中沒有為 user_r 角色分配這些權限。

在 SELinux 中，類型（Type） 是安全上下文中最重要的部分之一。

它決定了主體（如進程）和客體（如文件、目錄、端口等）之間的訪問權限。

通過定義哪些類型的主體可以訪問哪些類型的客體，SELinux 實現了細粒度的強制訪問控制（MAC）。

類型描述
httpd_t Web 服務進程類型（Nginx/Apache）
httpd_sys_content_t Web 服務器內容文件類型
httpd_log_t Web 服務器日志文件類型
sshd_t SSH 服務進程類型
mysqld_t MySQL 數據庫進程類型
user_t 普通用戶進程類型

類型	描述
`httpd_t`	Web 服務進程類型（Nginx/Apache）
`httpd_sys_content_t`	Web 服務器內容文件類型
`httpd_log_t`	Web 服務器日志文件類型
`sshd_t`	SSH 服務進程類型
`mysqld_t`	MySQL 數據庫進程類型
`user_t`	普通用戶進程類型

level 是可選的，表示 敏感級別或分類信息 。它主要用于實現更高級別的數據隔離和訪問控制。
system_u:object_r:httpd_sys_content_t:s0
這里的 s0 就是 level 字段，表示最低的安全級別。
staff_u:staff_r:staff_t:s0:c0,c2
這里 s0:c0,c2 表示該對象/用戶屬于 s0 級別，并具有類別 c0 和 c2。

多級安全策略（MLS）

MLS 是一種經典的安全模型，將信息分為多個等級（Sensitivity Level） ，例如：

等級描述
s0 非密級
s1 秘密
s2 機密
s3 絕密

MLS 規則：

用戶只能讀取 等于或低于自己安全等級 的資源。

用戶只能寫入 等于或高于自己安全等級 的資源。

這種方式保證了高安全等級的信息不會被低權限用戶修改或泄露。

在大多數系統中，只用到了 s0 (最多支持到 s15)，除非啟用了 MLS（多級安全策略）并做了特殊配置。

等級	描述
`s0`	非密級
`s1`	秘密
`s2`	機密
`s3`	絕密

多類別安全策略（MCS）

MCS 是 MLS 的一個輕量級變體，通常用于 Linux 桌面環境和容器中，比如 Docker。

MCS 使用“類別”（Categories）來對數據進行分類，而不是嚴格的等級劃分。
s0:c0.c5 或 s0:c0,c2,c4
其中：

s0：統一使用最低等級

c0, c1, ..., c1023：最多支持 1024 個類別編號

MCS 規則：

某個進程只能訪問與其類別集合完全匹配或包含其類別的資源 。

類似于標簽機制，用于隔離不同用戶的資源。

當運行一個 Docker 容器時，它可能會被自動賦予類似這樣的上下文：
system_u:system_r:container_t:s0:c0,c2
這表示：

這個容器進程屬于：

SELinux 用戶 system_u

角色 system_r

類型 container_t

安全級別為 s0

屬于類別 c0 和 c2

同時，它的文件系統也會被打上相同的標簽。這樣做的目的是：

讓這個容器只能訪問帶有 c0,c2 類別的資源，不能訪問其他容器的數據。

SELinux 中的 level 字段有以下幾種形式：

格式含義示例
s0 單一層級（適用于 MLS 或 MCS） system_u:object_r:httpd_t:s0
s0-s15 層級范圍（最小到最大） user_u:user_r:user_t:s0-s15
s0:c0.c1023 包含所有類別（常見于 MCS） staff_u:staff_r:staff_t:s0:c0.c1023
s0:c0,c2,c5 指定具體類別 root:sysadm_r:sysadm_t:s0:c0,c2,c5

使用 MCS 實現 Docker 容器隔離

當運行兩個 Docker 容器時，它們會被自動分配不同的 MCS 標簽，例如：

容器 A：system_u:object_r:container_file_t:s0:c1,c2

容器 B：system_u:object_r:container_file_t:s0:c3,c4

這確保了兩個容器無法互相訪問對方的文件系統，即使它們運行在同一臺主機上。

格式	含義	示例
`s0`	單一層級（適用于 MLS 或 MCS）	`system_u:object_r:httpd_t:s0`
`s0-s15`	層級范圍（最小到最大）	`user_u:user_r:user_t:s0-s15`
`s0:c0.c1023`	包含所有類別（常見于 MCS）	`staff_u:staff_r:staff_t:s0:c0.c1023`
`s0:c0,c2,c5`	指定具體類別	`root:sysadm_r:sysadm_t:s0:c0,c2,c5`

問: 如果兩個容器的 SELinux 標簽都是 c1，那它們之間可以互相訪問嗎？

不一定能互相訪問。

但至少在 SELinux 的 MCS（多類別安全）機制上，它們具備“可能被允許訪問”的前提條件。

策略（Policy）

策略是 SELinux 的“規則本”，它是一組預定義的 訪問控制規則 ，決定某個主體是否可以對某個客體執行某種操作。

某個進程（如 httpd_t）是否可以讀取 /var/www/html/ 下的文件（httpd_sys_content_t）
是否允許 nginx 訪問非標準端口（如 8080）
是否允許普通用戶啟動某些服務

策略 = “誰可以對什么做什么”的規則集合。

SELinux 策略包含了一系列 允許規則（allow rules） ，這些規則定義了哪些類型的主體可以對哪些類型的客體執行哪些操作。
allow httpd_t httpd_sys_content_t:file { read };
這條規則表示：

主體類型 httpd_t（Web 服務器進程）

可以對客體類型 httpd_sys_content_t（Web 服務器內容文件）

執行 read 操作

實例分析

我們以 Nginx 為例，演示 SELinux 如何使用上述四個概念進行訪問控制。

場景描述：

主體：nginx 進程（類型為 httpd_t）

在 SELinux 中，每個運行中的進程都有一個 安全上下文（Security Context） ，其中包含它的 類型（type） 。

它是由 SELinux 策略模塊（如 httpd.pp）中定義的，用于標識 Web 服務器進程的標準類型。

httpd_t：Web 服務進程本身

httpd_sys_content_t：網頁文件

httpd_log_t：日志文件

httpd_port_t：允許綁定的端口
ps -Z -C nginx
?
LABEL ? ? ? ? ? ? ? ? ? ? ? ? ? ?  PID TTY ? ? ? ?  TIME CMD
system_u:system_r:httpd_t:s0 ? ?  5918 ? ? ? ?  00:00:00 nginx

客體：網頁文件 /var/www/html/index.html（類型為 httpd_sys_content_t）

ls -Z /usr/share/nginx/html/index.html
system_u:object_r:httpd_sys_content_t:s0 /usr/share/nginx/html/index.html

安全上下文：

進程：system_u:system_r:httpd_t:s0
文件：system_u:object_r:httpd_sys_content_t:s0

策略規則：

allow httpd_t httpd_sys_content_t : file { read };

由于策略允許 httpd_t 類型的進程讀取 httpd_sys_content_t 類型的文件，所以 Nginx 成功加載頁面內容。

如果文件的安全上下文不是 httpd_sys_content_t，比如是 user_t，那么即使權限正確，SELinux 也會阻止訪問，并記錄 AVC 日志。

1.3 運行模式

SELinux 是 Linux 系統中的一個強制訪問控制機制（MAC），它的行為取決于當前所處的運行模式。

可以通過以下命令查看當前 SELinux 模式：

SELinux 是 Linux 系統中的一個強制訪問控制機制（MAC），它的行為取決于當前所處的運行模式。

可以通過以下命令查看當前 SELinux 模式：

getenforce

輸出可能是：

Enforcing

或

Permissive

或

Disabled

`enforcing`（強制模式）

這是 SELinux 的正常工作模式，也是最安全的模式。

在這個模式下，SELinux 不僅記錄違規行為，還會實際阻止非法訪問。

特性	描述
是否執行策略	是
是否阻止非法訪問	是
是否記錄日志	是（記錄在 `/var/log/audit/audit.log` 中）

生產環境必須啟用此模式以保障系統安全
所有服務和應用都已正確配置 SELinux 上下文和策略

如果運行了一個 Web 服務器（如 Nginx），但它試圖訪問一個沒有被標記為 httpd_sys_content_t 的文件，SELinux 將直接拒絕訪問，并記錄到日志中。

`permissive`（寬容模式）

在這個模式下，SELinux 只記錄違規行為，不會真正阻止任何操作。

特性	描述
是否執行策略	是
是否阻止非法訪問	否
是否記錄日志	是

調試新服務時，避免因 SELinux 阻止導致服務啟動失敗
排查 AVC（Access Vector Cache）拒絕日志
測試自定義策略模塊是否有效

如果服務因為 SELinux 標簽錯誤而無法讀取某個文件，在 permissive 模式下仍然可以運行，但會在日志中看到一條“AVC denied”信息。

`disabled`（禁用模式）

這個模式表示完全關閉 SELinux，它不再加載策略、不記錄、也不干預任何操作。

特性	描述
是否執行策略	否
是否阻止非法訪問	否
是否記錄日志	否

在安裝或調試階段，為了快速排除 SELinux 干擾
不需要 SELinux 提供額外安全保護的測試環境

注意：強烈不建議在生產環境中長期使用此模式，因為它會帶來嚴重的安全風險。

模式	是否執行策略	是否阻止非法訪問	是否記錄日志	安全級別	推薦用途
`enforcing`	是	是	是	高	生產環境
`permissive`	是	否	是	中	調試、排錯
`disabled`	否	否	否	低	完全不需要 SELinux 的環境

狀態與模式管理

查看 SELinux 當前狀態

sestatus

查看當前運行模式

getenforce

臨時切換 SELinux 模式（無需重啟）

setenforce 只能在 SELinux 未被永久禁用 的情況下使用。

# 切換到寬容模式
setenforce 0
?
# 切換回強制模式
setenforce 1

永久更改 SELinux 模式（需修改配置文件）

編輯配置文件：

sudo vi /etc/selinux/config

設置以下參數之一：

SELINUX=enforcing ? # 推薦生產環境使用
# 或
SELINUX=permissive ?# 調試時使用
# 或
SELINUX=disabled ? ?# 不推薦，除非特殊需求

保存后重啟系統生效：

reboot

1.4 安全上下文管理

查看文件/目錄的 SELinux 上下文

ls -Z /usr/share/nginx/html/

輸出格式：

system_u:object_r:httpd_sys_content_t:s0 index.html

修改文件類型（Type）

chcon -t httpd_sys_content_t /path/to/file
chcon -R -t httpd_sys_content_t /var/www/mynginx

讓 Web 服務進程（如 Nginx 或 Apache）能夠訪問 /var/www/mynginx 目錄下的內容。

因為 SELinux 默認策略中規定：

Web 服務進程運行在 httpd_t 類型下

它只能訪問具有 httpd_sys_content_t 類型的文件或目錄

如果把網頁文件放在一個沒有正確打上 SELinux 標簽的目錄里（比如默認不是 /var/www/html），Nginx/Apache 可能會被 SELinux 拒絕訪問，即使 Linux 文件權限是 755 也不行。

把網頁文件放在了 /var/www/mynginx/index.html

啟動了 Nginx

瀏覽器訪問時出現 403 Forbidden 錯誤

檢查 SELinux 日志（/var/log/audit/audit.log）可能會看到類似這樣的 AVC 拒絕：
type=AVC msg=audit(1234567890.123:456): apparmor="DENIED" ...
或者：
type=AVC msg=audit(...): avc: denied { read } for pid=... comm="nginx" name="index.html" dev="..." ino=...
這說明 SELinux 阻止了 Nginx 對這個文件的訪問。

此時運行：
chcon -R -t httpd_sys_content_t /var/www/mynginx
就能解決這個問題 —— 讓 Nginx 正常讀取這些文件。

使用 chcon 設置的是臨時標簽，重啟后會丟失。

持久化設置

添加持久化規則

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/mynginx(/.*)?"

應用更改

restorecon -Rv /var/www/mynginx

1.5 日志分析與調試

當 SELinux 阻止某個操作時（比如 Nginx 無法讀取某個網頁文件），就會生成一條 AVC denied 日志

這條日志會被記錄到 /var/log/audit/audit.log 中

使用 ausearch -m avc 就可以查看這些“被拒絕的訪問”記錄

查看 SELinux 拒絕日志（AVC）

sudo ausearch -m avc -ts recent
?

查看最近發生的 SELinux 訪問被拒絕事件

運行命令后，可能會看到類似這樣的輸出：

type=AVC msg=audit(1723456789.123:456): avc: denied { read } for pid=1234 comm="nginx" name="index.html" dev="sda1" ino=123456 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

字段	含義
`pid=1234`	被拒絕的進程 PID
`comm="nginx"`	是哪個程序被拒絕（這里是 nginx）
`name="index.html"`	被訪問的文件名
`scontext=...`	主體的安全上下文（即 nginx 進程的身份）
`tcontext=...`	客體的安全上下文（即 index.html 文件的身份）
`tclass=file`	被訪問的目標類型是文件
`{ read }`	被拒絕的操作是“讀取”

分析拒絕原因

sudo ausearch -m avc -ts recent | audit2why
?
Was caused by:
The type httpd_t is not allowed to read files of type default_t.

1.6 實戰案例

正在部署一個基于 Nginx 的網站，并希望使用 SELinux 來保護該服務，防止未經授權的訪問。

安裝 Nginx 和 SELinux 工具

正在部署一個基于 Nginx 的網站，并希望使用 SELinux 來保護該服務，防止未經授權的訪問。

安裝 Nginx 和 SELinux 工具

sudo yum install -y nginx policycoreutils-python-utils setools setools-console

創建自定義網頁目錄并設置權限

sudo mkdir -p /var/www/mynginx
sudo echo "Hello from SELinux Protected Nginx" > /var/www/mynginx/index.html
sudo chown -R nginx:nginx /var/www/mynginx

步驟 3：設置正確的 SELinux 上下文

-- 設置SELinux規則
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/mynginx(/.*)?"
?
-- 重新加載規則
sudo restorecon -Rv /var/www/mynginx

步驟 4：配置 Nginx 使用新目錄

編輯默認站點配置：

sudo vi /etc/nginx/nginx.conf

修改內容如下：

server {listen ? ? ? 80;server_name  localhost;
?location / {root ? /var/www/mynginx;index ?index.html index.htm;try_files $uri $uri/ =404;}
}

步驟 5：啟動 Nginx 并測試訪問

systemctl restart nginxcurl localhost

步驟 6：模擬 SELinux 拒絕并修復

將網頁目錄改為 /opt/mynginx，但未設置 SELinux 上下文，此時訪問可能失敗。

檢查日志：

sudo ausearch -m avc -ts recent | audit2why

輸出可能提示：

Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.

二、加密技術介紹

隨著云計算的廣泛應用，數據在共享和傳輸過程中的安全性面臨嚴峻挑戰。

加密技術作為保障信息安全的核心手段，在云計算環境中發揮著至關重要的作用。

對稱加密（Symmetric Encryption）

使用同一把密鑰進行加密和解密。

想象有一個保險箱，用一把鑰匙把它鎖上，別人拿到這個保險箱后，也需要用同一把鑰匙才能打開。

明文↓
[ 加密 ] —— 使用 密鑰 K↓
密文↓
[ 解密 ] —— 使用 相同的密鑰 K↓
明文

關鍵點：

發送方和接收方必須提前共享同一個密鑰。
如果密鑰泄露，數據就不再安全。
優點是速度快，適合大量數據加密。

非對稱加密（Asymmetric Encryption）

使用一對密鑰：公鑰（Public Key）和私鑰（Private Key）

公鑰：所有人都可以知道，用于加密
私鑰：只有自己持有，用于解密

想象有一把鎖，任何人都可以用它來鎖一個箱子（用的公鑰加密），但只有能打開這個箱子（用的私鑰解密）。

明文
? ↓
[ 加密 ] —— 使用接收方的公鑰 PK
? ↓
密文
? ↓
[ 解密 ] —— 使用接收方的私鑰 SK
? ↓
明文

關鍵點：

不需要提前共享密鑰
更安全，但速度較慢
適用于身份驗證、數字簽名等場景

混合加密系統（Hybrid Encryption）

結合對稱加密和非對稱加密的優點：

用非對稱加密傳輸對稱密鑰（確保安全）
然后用對稱加密處理大量數據（確保效率）

[客戶端] 想發送大量數據給 [服務器]1. 客戶端生成一個隨機對稱密鑰 K2. 客戶端使用服務器的公鑰 PK 加密 K：K_encrypted = Encrypt(K, PK)3. 客戶端發送 K_encrypted 給服務器4. 服務器用自己的私鑰 SK 解密：K = Decrypt(K_encrypted, SK)5. 后續所有通信都使用 K 進行對稱加密：[客戶端] ←加密數據→ [服務器]

優勢：

安全性高（非對稱加密保護密鑰）
效率高（對稱加密處理數據）

三、CA

CA是Certificate Authority的縮寫，通常翻譯成認證權威或者認證中心。

其主要用途是為用戶發放數字證書，并管理證書的生命周期，包括證書的發布、更新、撤銷和驗證。

證書發布：向申請者發放經過驗證的數字證書。
證書更新：在證書即將過期或信息變更時，提供更新服務。
證書撤銷：當證書不再有效或被濫用時，將其從信任列表中移除。
證書驗證：確保證書的有效性和真實性。

作用

身份認證：通過數字證書確認實體的身份，防止假冒和欺詐行為。
數據的不可否認性：確保通信雙方無法否認已發送或接收的信息，增強交易的安全性和可靠性。

每個主流操作系統（如Windows、macOS、Linux發行版）以及大多數現代瀏覽器都內置了一組受信任的證書頒發機構（Certificate Authorities, CA）的根證書。

這些預裝的根證書構成了所謂的“信任鏈”，允許操作系統或瀏覽器驗證網站提供的SSL/TLS證書的真實性。

當訪問一個HTTPS網站時，如果該網站使用的是由已知且受信任的CA簽發的證書，則瀏覽器會自動完成以下步驟：

下載服務器證書：當客戶端（比如瀏覽器）嘗試建立與服務器的安全連接時，服務器會發送它的SSL/TLS證書給客戶端。

構建信任鏈：這個證書通常不是直接由根CA簽發的，而是由中間CA簽發的。因此，服務器還會提供一個或多個中間證書，以便客戶端可以構建從服務器證書到某個已知根證書的信任鏈。

驗證證書：客戶端檢查證書的有效性（包括但不限于是否過期、域名是否匹配），并且確保證書是由一個它信任的根CA簽發的。

顯示安全標志：如果所有檢查都通過了，瀏覽器地址欄會顯示鎖圖標或其他形式的安全標識，表示連接是安全的。

由于大部分公共網站都會使用知名CA（例如DigiCert、GlobalSign、Let's Encrypt等）提供的證書，并且這些CA的根證書已經被預先安裝在操作系統和瀏覽器中，所以用戶不需要進行任何額外的操作即可享受加密通信帶來的安全保障。

3.1 證書請求文件（CSR）

CSR是Certificate Signing Request的英文縮寫，即證書請求文件。

它是證書申請者在申請數字證書時由CSP（加密服務提供者）在生成私鑰的同時也生成的文件。

生成過程

生成私鑰：證書申請者首先生成一個私鑰，用于后續的加密操作。
生成CSR文件：使用私鑰生成包含申請者信息的CSR文件，這些信息包括但不限于組織名稱、域名等。
提交CSR文件：將CSR文件提交給證書頒發機構（CA）進行審核。

簽發過程

CA審核：CA對CSR文件中的信息進行審核，確認申請者的身份和信息的真實性。
簽名證書：審核通過后，CA使用其根證書的私鑰對CSR文件進行簽名，生成最終的數字證書并頒發給申請者。

自簽名證書是指由其自身而非受信任的證書頒發機構（CA）簽發的數字證書。

通常用于開發環境、內部網絡或測試目的，因為它不需要支付費用給第三方CA，且可以快速生成。

然而，由于它們不是由瀏覽器或操作系統信任的CA簽發的，使用自簽名證書時會遇到一些特定的問題和限制。

3.2 HTTPS

HTTPS（Hyper Text Transfer Protocol Secure）是HTTP的安全版本，通過SSL（Secure Sockets Layer）或其后續技術TLS（Transport Layer Security）為數據傳輸提供加密。

工作流程

客戶端（瀏覽器） ? ? ? ? ? ? ? ? ? ? ? ?服務器

? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|---(1) 發送HTTPS請求--------------->|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|<---(2) 返回數字證書（含公鑰）------|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|--(3) 驗證證書有效性 ? ? ? ? ? ? ? |
? ? ?| ? (確認未過期、CA可信等) ? ? ? ? ? |
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|---(4) 使用公鑰加密對稱密鑰-------->|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|-(5) 使用私鑰解密得到對稱密鑰
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|<--(6) 確認安全通道建立成功--------|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|---(7) 開始通過HTTPS傳輸數據（加密）|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
? ? ?|<---(8) 接收加密數據并解密----------|
? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|

圖示說明

步驟1：客戶端發起HTTPS連接請求。
步驟2：服務器響應請求，返回其數字證書（包含服務器的公鑰）。
步驟3：客戶端驗證服務器提供的證書是否有效且由可信賴的CA簽發。
步驟4：如果證書驗證成功，客戶端生成一個隨機的對稱密鑰，并使用服務器提供的公鑰對其進行加密后發送給服務器。
步驟5：服務器接收到加密的對稱密鑰后，使用自己的私鑰進行解密，從而獲取到對稱密鑰。
步驟6：雙方確認已成功建立了一個安全的通信通道。
步驟7：客戶端和服務器開始使用之前協商好的對稱密鑰加密所有后續的數據交換。
步驟8：任何一方發送的數據都會被加密，另一方接收時則會解密這些信息。

3.3 應用證書

安裝必要的軟件包

yum install -y httpd mod_ssl openssl

mod_ssl 是 Apache 的 SSL/TLS 支持模塊

openssl 是用于生成密鑰、證書的核心工具

搭建私有CA

我們先創建一個本地CA來簽發服務器證書，模擬正式CA的工作流程。

mkdir -p ~/myCA/{certs,crl,private,newcerts}
?
cd ~/myCA

certs/：存放已簽發的證書
crl/：吊銷列表
private/：CA私鑰存儲
newcerts/：新證書存放目錄
還需要兩個輔助文件：

echo '01' > serial ? ? ?# 下一個證書編號
?
touch index.txt ? ? ? ? # 證書數據庫

生成CA私鑰

openssl genrsa -out private/ca.key.pem 4096
?
chmod 400 private/ca.key.pem

-out private/ca.key.pem：輸出文件名
4096：密鑰長度（推薦至少2048位）
chmod 400：保護私鑰權限，防止泄露

生成CA自簽名證書

openssl req -x509 -new -key private/ca.key.pem -sha256 -days 3650 -out certs/ca.cert.pem

-x509：直接生成X.509證書（不是CSR）
-new：新建請求
-sha256：哈希算法
-days 3650：有效期10年
系統會提示輸入一些信息，如國家、組織名稱等（這些信息將顯示在證書中）

Country Name (2 letter code) [XX]:CN
State or Province Name (full name) []:guangzhou
Locality Name (eg, city) [Default City]:shenzhen
Organization Name (eg, company) [Default Company Ltd]:alibaba
Organizational Unit Name (eg, section) []:ops team
Common Name (eg, your name or your server's hostname) []:www.zking.com
Email Address []:123@qq.com

證書簽發后，只有當客戶端（如瀏覽器）訪問的域名與證書中的 Common Name 匹配時，才不會提示“證書不安全”。

生產環境下不能隨便填

在正式部署 HTTPS 的時候，Common Name 必須是真實擁有的域名，并且由正規 CA 簽發證書。

此時已經有了一個私有CA，其證書是 certs/ca.cert.pem，私鑰是 private/ca.key.pem。

[root@localhost myCA]# tree
.
├── certs
│?? └── ca.cert.pem
├── crl
├── index.txt
├── newcerts
├── private
│?? └── ca.key.pem
└── serial

生成SSL密鑰和證書請求

假設要為域名 zking 配置HTTPS。

生成服務器私鑰

openssl genrsa -out /etc/pki/tls/private/zking.key 2048chmod 400 /etc/pki/tls/private/zking.key

注意路徑 /etc/pki/tls/private/ 是 Red Hat 系統標準位置

生成證書簽名請求（CSR）

openssl req -new -key /etc/pki/tls/private/zking.key -out /tmp/zking.csr

系統會再次提示填寫相關信息，其中 Common Name 應該填的域名，比如：

Common Name (e.g. server FQDN or YOUR name) []: www.zking.com

A challenge password []: zking為證書申請過程增加一層額外的身份驗證zking。

當向某些 CA（證書頒發機構）提交 CSR 以申請證書時，CA 可能會要求提供這個“挑戰密碼”來確認是 CSR 的創建者。

簽發服務器證書

現在我們用之前創建的CA來簽發服務器證書。

openssl x509 -req -in /tmp/zking.csr \-CA certs/ca.cert.pem \-CAkey private/ca.key.pem \-CAcreateserial \-out /etc/pki/tls/certs/zking.crt \-days 365 \-sha256

-CA：指定CA證書
-CAkey：指定CA私鑰
-CAcreateserial：自動創建serial文件
-out：輸出最終的服務器證書
-days 365：證書有效期1年

此時已經擁有了完整的服務器證書鏈：

私鑰：/etc/pki/tls/private/zking.key
證書：/etc/pki/tls/certs/zking.crt
CA證書：~/myCA/certs/ca.cert.pem

配置Apache啟用HTTPS

編輯 Apache 的 SSL 虛擬主機配置文件（/etc/httpd/conf.d/ssl.conf）

sudo vi /etc/httpd/conf.d/ssl.conf

找到如下配置并修改為：

<VirtualHost *:443>ServerName www.zking.comSSLEngine onSSLCertificateFile "/etc/pki/tls/certs/zking.crt"SSLCertificateKeyFile /etc/pki/tls/private/zking.key
</VirtualHost>

配置項	說明
`SSLEngine on`	啟用SSL
`SSLCertificateFile`	服務器證書路徑
`SSLCertificateKeyFile`	服務器私鑰路徑

重啟Apache服務

sudo systemctl restart httpdsudo systemctl enable httpd --now

檢查是否監聽了443端口：

ss -tuln | grep 443

測試訪問

在瀏覽器中訪問：

https://www.zking.com

由于使用的是自簽名CA證書，瀏覽器會提示“不安全連接”或“證書不受信任”。

可以手動將 ca.cert.pem 導入瀏覽器或操作系統信任庫中解決此問題。

# 步驟1：確認的 CA 證書存在
ls -l /root/myCA/certs/ca.cert.pem
?
# 步驟2：復制 CA 證書到系統信任目錄（推薦使用 .crt 后綴）
sudo cp /root/myCA/certs/ca.cert.pem /etc/pki/ca-trust/source/anchors/myCA.crt
?
# 步驟3：更新系統信任庫
sudo update-ca-trust
?
# 步驟4：驗證是否生效
curl -v https://www.zking.com

如果以后想刪除這個證書：

sudo rm /etc/pki/ca-trust/source/anchors/myCA.crt
sudo update-ca-trust

文件路徑	內容
`/etc/pki/tls/private/zking.key`	服務器私鑰
`/etc/pki/tls/certs/zking.crt`	服務器證書
`~/myCA/certs/ca.cert.pem`	自簽名CA證書
`~/myCA/private/ca.key.pem`	CA私鑰（非常重要，不能泄露）

步驟	目標
搭建CA	創建自己的證書頒發機構
生成私鑰 & CSR	為服務器生成密鑰和證書請求
簽署證書	使用CA簽發服務器證書
配置Apache	修改 ssl.conf 文件啟用HTTPS
瀏覽器測試	訪問 https://zking 并驗證安全性

3.4 Nginx 啟用證書

打開或創建 Nginx 的站點配置文件

sudo vi /etc/nginx/nginx.conf

2. 修改內容

server {listen 80;server_name www.zking.com;# 強制跳轉到 HTTPSreturn 301 https://$host$request_uri;
}server {listen 443 ssl;server_name www.zking.com;# 指定 SSL 證書和私鑰路徑ssl_certificate     /etc/pki/tls/certs/zking.crt;ssl_certificate_key /etc/pki/tls/private/zking.key;# 推薦的安全協議和加密套件ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers HIGH:!aNULL:!MD5;# 根目錄設置（根據的實際需求修改）location / {root   /usr/share/nginx/html;index  index.html index.htm;try_files $uri $uri/ =404;}}

重啟 Nginx 生效配置