Kanji
・雲端架構工程師 / 自由職業 ・1993年出生 ・愛媛縣出身 / 現居東京都澀谷區 ・5年 AWS 實戰經驗 個人檔案詳情
目錄
AWS Config（以下簡稱Config）是一項監控AWS資源的配置和更改的服務。Config只能獲取AWS資源的配置資訊，無法獲取作業系統、應用程式、資料庫等的配置資訊。
Config 可以記錄的 AWS 資源有限制，請謹慎使用。例如，無法記錄組織等資源、IAM Identity Center、Systems Manager Parameter Store 和文件等所有資源。
參考： AWS Config 支援的資源型別 - AWS Config
除了管理 AWS 資源配置之外，Config 還可以使用 AWS Config 規則（以下簡稱 Config 規則）監控資源設定。
當Config檢測到配置更改時，它可以根據設定的規則判斷資源是否不合規，如果是，則傳送通知。
在本地環境中，配置管理和更改跟蹤通常使用 Excel 和 Word 等文件進行處理。在更加自動化的系統中，可以使用 Ansible 執行作業系統的配置管理。
AWS中的配置資訊可以透過AWS Config來記錄，但是如上所述，可以記錄的資源是有限制的。雖然主要的AWS資源可以被跟蹤，但對於Config無法跟蹤的資源，需要考慮如何記錄更改。
此外，使用 Config Rules 時，先決條件是使用 Config 記錄目標 AWS 資源中的更改。
通常建議為所有 AWS 賬戶啟用 Config。但是，如果“使用另一個配置管理工具而不是 Config 來管理配置和更改”和“使用另一個安全檢查工具而不是 Config Rules 檢查配置缺陷”，那麼不實現 Config 也是一種選擇。
對於“使用另一個配置管理工具而不是 Config 來管理配置和更改”，使用 IaC 工具是一種選擇，但根據開發人員和操作人員的技能水平，要求整個系統使用 IaC 工具可能會很困難。
如果全公司採用另一種 SaaS 工具，最好使用該工具。
對於“使用其他安全檢查工具而不是配置規則檢查配置缺陷”，可以使用以下選項：
當使用Config Rules作為安全工具時，需要明確公司必須滿足的安全規則。Depending on these rules, it may be better to check for configuration deficiencies with another security check tool instead of using Config Rules.
由於從頭開始建立配置規則很困難，因此透過使用基於這些要求的一致性包或 Security Hub 標準來建立配置規則來滿足安全要求是有效的。
AWS Config 的一致性包示例模板 - AWS Config
Security Hub 標準參考 - AWS Security Hub
如果沒有特定的安全規則，建議首先在 Security Hub 中實施 AWS 基礎安全最佳實踐 (FSBP) 或 AWS 架構完善的框架一致性包推薦的配置規則。
AWS 基礎安全最佳實踐 v1.0.0 (FSBP) 標準 - AWS Security Hub
AWS 架構完善的框架可靠性支柱的操作最佳實踐 - AWS Config
AWS 架構完善的框架安全支柱的操作最佳實踐 - AWS Config
AWS 基礎安全最佳實踐 (FSBP) 和 AWS 架構完善的框架都是 AWS 提供的最佳實踐，但 AWS 基礎安全最佳實踐更關注安全性。
將 Config 規則設定為護欄時，需要選擇 Config 將跟蹤哪些 AWS 資源。但是，與情況 1 和 2 一樣，過多的跟蹤會產生成本，因此應根據每個 AWS 賬戶中資源的特性來選擇資源。
配置通常由基礎設施團隊管理，但由於只有系統管理員瞭解成員帳戶中的資源，因此最好使用內部工作流程在應用程式基礎上進行管理。
在情況 3 中，如果可以透過 CI/CD 管道中的安全檢查進行預防性控制，而不是透過 Config 進行檢測控制，則無需使用 Config 進行跟蹤。但是，如果存在手動更改執行期間部署的資源的情況，則應考慮使用 Config 進行跟蹤。
參考： 使用 AWS Config 記錄 AWS 資源 - AWS Config
使用 Control Tower 啟用 Config 時，可以使用以下部落格中描述的解決方案在頒發 AWS 賬戶時自動排除 Config 跟蹤的資源。
在AWS Control Tower環境中自定義AWS Config資源跟蹤|AWS 雲運營部落格
在[2.]中粗略決定安全規則和框架之後。公司必須滿足哪些安全規則？](#2-what-security-rules-must-the-company-meet)，有必要制定更詳細的規則。
如果您按原樣應用配置規則的一致性包或Security Hub標準，那麼也會設定不太重要的規則，因此僅選擇真正需要解決的規則。
此規則選擇是一項勞動密集型任務。
最好排除可由其他控制措施解決的規則，例如 SCP 和身份訪問管理等預防性控制 AWS 服務，以及 GuardDuty 等其他檢測控制 AWS 服務。
每個公司的選擇過程各不相同，很難提供示例，所以說明到此為止。
1 和 2 通常由基礎設施團隊處理，但 3 通常由可以對系統進行更改的系統管理員處理。
例如，如果檢測到EC2 EBS未加密，則需要考慮更改的影響並採取糾正措施，因此係統管理員將處理該操作。
Config還可以執行修復操作，因此在某些情況下，不合規的資源會被自動糾正。
如果使用IaC部署，會與原始碼中定義的配置有出入，所以需要告知開發者實現情況。
Config 跟蹤的資源變更歷史記錄可能會被基礎設施團隊和系統管理員雙方使用，但 Config 日誌往往集中儲存在日誌管理賬戶中，系統管理員可能無法使用 Athena 分析日誌。
即使在組織級別啟用了 Config，系統管理員也可以使用高階查詢來分析自己的 AWS 賬戶的日誌。
參考： 使用 AWS Config 查詢 AWS 資源的當前配置狀態 - AWS Config