背景

在很多企業的實際應用場景中，特別是金融類的客戶，大部分的應用都是部署在私有子網中，如何能夠讓客戶的開發人員和運維人員從本地的數據中心中安全的訪問云上資源，堡壘機是一個很好的選擇。傳統堡壘機的核心實現原理是基于SSH協議的安全連接，通常運用SSH（Secure Shell）協議實現數據的加密通信。SSH為安全身份驗證和數據加密提供了可靠保障，從而確保了連接的安全性。然而，傳統的自建堡壘機在其管理和運維方面面臨著多種挑戰：

部署與維護復雜性：自建堡壘機的部署和配置往往涉及多個復雜步驟和組件，導致管理和維護的工作量顯著增加。

安全性風險：自行管理多個密鑰和憑證可能會增加安全漏洞的風險。若密鑰管理不當，可能導致未經授權的訪問。

可用性問題：自建堡壘機常常無法實現高可用性和彈性，多用戶同時訪問時可能出現性能問題，影響用戶體驗。

擴展困難：隨著用戶數量和需求的增加，自建堡壘機可能難以靈活擴展，導致資源分配不均。

更新和升級：自建堡壘機需要定期進行更新和升級，以保持安全性和性能，然而這可能會導致業務中斷或不穩定情況。

外網暴露：傳統堡壘機需要在云上環境中部署一個有外網訪問的權限的機器，增加了被攻擊的風險。

與傳統方式不同，基于Amazon Systems Manager Session Manager的堡壘機通過建立雙向加密通道，連接客戶端和遠程節點，并采用TLS 1.2進行流量加密和Sigv4簽名請求。這一方式具備顯著優勢：

一鍵式部署：該方案極大簡化了堡壘機部署流程，從而減少了部署難度和運維成本。

卓越安全性：Session Manager提供了加密和身份驗證功能，保障連接的安全性。

a. 基于AWS Identity and Access Management（IAM）角色的最小權限原則，管理員能夠通過集中的IAM策略管理堡壘機的訪問授權。

b. 無需管理堡壘機密鑰。

c. 支持云上私有子網部署，無需部署在公有子網中，且無需打開入站端口。

高可用性：通過彈性伸縮功能實現了堡壘機的跨可用區高可用性。

可擴展性：基于CPU利用率的彈性伸縮策略能夠自動調整容量，以適應不同流量訪問的需求。

簡化管理：Systems Manager Session Manager是一項無需用戶自行管理實例的托管服務。無需預先啟動實例，也無需將實例直接暴露在公網上，從而降低了管理復雜性。

端口轉發與跨平臺支持：通過Session Manager，可在本地客戶端進行遠程節點端口轉發，并實現連接。同時，它對Linux、Windows、Mac等多種操作系統平臺提供了跨平臺訪問支持。

全面的日志記錄與審計：Session Manager支持多種方式進行日志記錄，涵蓋登錄時間、命令執行等內容，以確保會話連接活動得到完整記錄。這些記錄可用于審計和故障排除。

提供監控告警功能：針對堡壘機的性能指標進行監控告警，以便在性能異常時及時收到通知。

基于Session Manager的堡壘機為訪問管理提供了高效、安全、高可用的解決方案，成為提升操作效率和保障安全性的理想選擇。堡壘機作為一種安全措施，允許用戶通過中間主機來訪問位于私有子網中的實例或資源。它作為一座橋梁，幫助用戶在安全的環境下連接到內部資源，同時減少對直接連接的需求，從而降低被攻擊的風險。對于企業的安全管理員來說，堡壘機可以增強安全性、簡化網絡配置、降低網絡資源暴露風險、提供審計跟蹤，對于開發運維人員來說，他們可以在本地環境中使用熟悉的開發、運維工具，如數據庫客戶端、瀏覽器、RDP等去訪問云上私有資源，大大提高生產效率。

本文主要闡述的是基于Amazon Systems Manager的Session Manager特性和Amazon EC2堡壘機的設計和實現。主要內容包括堡壘機的架構設計、安全設計、日志監控設計、高可用彈性設計以及自動化部署設計等，同時針對堡壘機在不同場景中的使用方式和腳本進行舉例說明。

云上堡壘機設計

安全設計

在進行云上堡壘機設計時，安全是第一個需要考慮的要求。Session Manager是一種無需通過公網IP或SSH密鑰來連接到EC2實例的服務，它通過Systems Manager的控制臺或CLI來創建和管理安全的交互式會話。其安全設計主要考慮以下四點：

IAM權限和訪問控制：

Session Manager權限：確保只有授權的用戶或角色擁有使用Session Manager的權限。為用戶或角色分配適當的IAM策略，限制其對Session Manager的訪問，一般情況下，通過與客戶已有的AD進行集成，通過分組來控制啟動Session Manager的權限。

多因素認證（MFA）：強制啟用多因素認證，增加用戶身份驗證的安全性。

VPC和子網安全性：

控制對Session Manager的網絡訪問：設置VPC Endpoints的安全組僅允許來自堡壘機及私有子網中主機的訪問，并且設置VPC Endpoints的策略，以限制特定受信任實體才能訪問。

日志和審計：

監控Session Manager會話：啟用CloudTrail以記錄Session Manager的API調用活動，以便審計和監控用戶對會話的操作；配置Session Manager參數，發送會話日志到Amazon CloudWatch日志組和S3存儲桶，確保用戶在會話中的所有操作均被記錄，CloudWatch日志組中的數據將保存3個月，S3桶中的會話日志將持久存儲以滿足安全監管和審計需求。同時，通過腳本來實現對本地Session Manager插件SSH登錄上的操作進行詳細記錄，并存儲在指定的存儲桶中。

安全加密：

加密各類堡壘機相關資源：使用Amazon Key Management Service（KMS）對Session Manager的會話進行加密，加密Amazon CloudWatch日志組及S3存儲桶，以確保會話和日志的安全性。

高可用和彈性設計

堡壘機的高可用設計可以確保在發生故障或負載增加時，堡壘機仍然能夠保持可用，并繼續提供安全的訪問控制。

堡壘機的高可用性

使用Auto Scaling Group（ASG）：配置堡壘機所在的EC2實例為一個Auto Scaling Group。當堡壘機實例的負載增加時，ASG會根據設置的擴展規則自動增加實例數量，保持高可用性。

設置負載均衡：當多個堡壘機實例同時運行時，可以使用負載均衡器來分發流量，確保各個實例的負載均衡。負載均衡器還可以在某些實例出現故障時自動將流量路由到其他健康的實例，提高了整體的可用性。

定時擴展和縮減

通過Auto Scaling Group的定時規則，控制堡壘機的啟動和關機時間，從而來節約堡壘機的費用。

監控告警設計

Amazon CloudWatch指標監控：CloudWatch可以監控EC2實例和其他亞馬遜云資源的性能指標。可監控實例的CPU使用率、內存利用率、磁盤等關鍵指標。并通過Amazon SNS服務設置報警，以便在性能異常時及時收到通知。

自動化部署設計

堡壘機代碼設計

考慮到堡壘機的高可用設計，在其中一臺機器宕機的情況下，可以自動、快速的拉起一臺新的堡壘機以供使用，我們采取EC2 launch template的方式進行堡壘機的構建，以下是IaC樣例代碼：

通過彈性伸縮啟動模版創建堡壘機的IaC代碼樣例，包含啟動模版、彈性伸縮組、彈性規則等。

2.定義堡壘機的EC2用戶數據代碼樣例

在創建堡壘機時，不僅僅是單獨的創建一臺EC2的實例，還需要針對用于該EC2的實例進行安全加固、安裝相應的工具、設置對于堡壘機的監控等功能，以下是IaC代碼中，用于EC2實例初始化的用戶數據（User Data）樣例。

3.設計和創建堡壘機安全組

根據Session Manager安全組的最佳實踐，本方案中堡壘機的安全組設計如下：

IaC代碼設計樣例如下：

Session Manager配置設計

在啟用Session Manager時，需要對Session Manager進行相關的配置，如是否開啟Session加密，是否將日志存儲到CloudWatch Logs或者S3上，是否對日志進行加密，最大的Session時長等。我們通過創建SSM Documents的方式來進行配置，如以下IaC樣例代碼所示：

堡壘機IAM角色設計

在本設計中，堡壘機的IAM角色主要包含以下權限：

AmazonSSMManagedInstanceCore

CloudWatchAgentServerPolicy

Logs部分權限

SSM Messages部分權限

S3部分權限

KMS部分權限

如需自定義更多Session Manager IAM角色的詳細可訪問：自定義Session Manager IAM角色

以下是IaC代碼樣例：

部署堡壘機

本章將介紹如何通過基礎設施即代碼（Infrastructure as code）的方式一鍵式構建云上堡壘機，通過Terraform進行相應的IaC代碼開發。

堡壘機部署架構圖

根據云上堡壘機的設計，我們在堡壘機的部署中，將使用到亞馬遜云上的多種服務：如Amazon CloudWatch、Key Management Service（KMS）、Identity and Access Management（IAM）、Systems Manager、Amazon Simply Notification Service（SNS）、Amazon Simple Storage Service（S3）、Amazon PrivateLink、Amazon EC2以及Amazon EC2 Auto Scaling等，以下為部署架構圖：

以下對部署中所使用到的主要亞馬遜云相關服務的用途進行簡單介紹：

Amazon EC2/Amazon EC2 Auto Scaling：在EC2上進行堡壘機的部署，并通過AutoScaling確保堡壘機的高可用；

Amazon Simple Storage Service（S3）：用于存放通過Session Manager和SSH登錄到堡壘機上所產生的操作日志信息；

Amazon VPC endpoints：用于堡壘機在沒有外網訪問的條件下，進行安全的訪問如Amazon CloudWatch（Logs/Monitoring）、Amazon S3、Systems Manager、Amazon KMS等服務；

Amazon CloudWatch：用于存放通過控制臺的Session Manager功能訪問堡壘機的操作日志存儲；

Amazon KMS：用于加密堡壘機部署過程中的相關服務，如Session加密、CloudWatch logs加密、S3桶加密等；

Amazon Simply Notification Service：用于接受Bastion Host在CPU/Memory/磁盤超過閾值的時候的告警信息。

需要創建的Endpoints列表：

堡壘機自動化部署

當IaC代碼開發完成后，可以將該代碼集成在其他資源的CICD pipeline中，也可以通過Terraform命令，直接進行部署。

等到命令執行完成后，登錄到亞馬遜云科技管理控制臺檢查相應資源是否按照預期部署完成。

堡壘機使用場景

堡壘機使用前置條件

如果要在本地機器上使用堡壘機，需要滿足以下條件：

確保亞馬遜云上堡壘機已經部署完成，并且處于running狀態；

確保網絡聯通性，確認堡壘機能訪問私網環境中的RDS數據庫、WebServer EC2等；

確保你本地使用的IAM角色至少具有以下權限：

ec2:DescribeInstances

ssm:StartSession

ec2-instance-connect:SendSSHPublicKey

確保本地環境中正確安裝了亞馬遜云命令行工具（CLI V2）和Session Manager插件

堡壘機使用場景實操

假設客戶在亞馬遜云上的私有子網中，部署了一個Web應用，包含Web前端和服務后端以及RDS數據庫（以SQL Server為例）。該客戶對于安全性的要求非常高，云上VPC環境中沒有Internet訪問，也沒有在本地網絡與云上環境之間搭建專線直連（Direct Connect）和VPN。但客戶的開發人員和運維人員，要求提供一個安全、高效、可靠的方式從本地的客戶端、應用程序、瀏覽器去訪問云上資源，以提高開發、運維效率。下圖為堡壘機實操環境的部署示意圖：

場景一：通過亞馬遜云科技管理控制臺/命令行登錄堡壘機

在這個場景中，開發人員或者運維人員通過公司AD集成的賬號拿到了相應的角色權限，直接登錄到亞馬遜云的管理控制臺，然后通過Session Manager直接連接到堡壘機上進行操作。操作步驟如下：

方式一：直接進入到EC2控制臺，選擇堡壘機，然后點擊“Connect”進行連接

方式二：進入到Systems Manager→Session Manager→Start Session，然后選擇堡壘機進行連接

兩種方式登錄后，進入的界面如下圖所示：

或者在本地啟動SSM Session Manager的插件，從本地電腦中，直接訪問堡壘機：

通過控制臺或者本地CLI進入到堡壘機后，所有的操作都會被記錄到Amazon CloudWatch Log Group“/aws/sessionmanager”，日志保留時間為3個月，并且還會上傳到S3桶（S3桶名：bastion-audit-log-bucket-，路徑為：ssm/）中做持久化存儲。

場景二：通過堡壘機實現遠程主機端口轉發

在該場景中，開發人員或者運維人員通過公司AD集成的賬號拿到了相應的角色權限，然后在本地啟動Session Manager插件來進行遠程主機的端口轉發，通過這種方式，開發人員或運維人員可以方便的使用本地客戶端進行操作云上資源，如訪問云上數據庫和訪問WebServer等。以下命令是啟動如何在本地機器上實現遠程主機端口轉發：

(1)遠端數據庫端口轉發

以在本地訪問云上SQLServer數據庫為例子，端口號為1433，本地端口號為12345，遠程主機DNS為：“bastion-test-db.xxxxx..rds.amazonaws.com”，啟動后，如下圖所示：

打開本地SQLServer客戶端，輸入RDS Server端地址和端口：“127.0.0.1,12345”，并輸入登錄數據庫的賬號和密碼，如下圖所示：

點擊“Connect”，即可訪問云上RDS數據庫并進行操作：

(2)遠端服務器端口轉發

以本地通過瀏覽器訪問Web Server為例，端口號為80，本地端口號為8080，遠程主機IP為：“10.99.3.132”，啟動后，如下圖所示：

通過本地瀏覽器訪問127.0.0.1:8080，可看到能夠成功訪問到位于私有網絡中的WebServer：

場景三：通過本地SSH連接到堡壘機

在開發人員或者運維人員在實際工作中，偶爾會需要通過SSH連接到堡壘機或者遠端的主機上進行調試或者運維，并上傳相應的文件到堡壘機上。一般情況下，運維人員需要拿到EC2的密鑰并確保安全組中包含有22端口及客戶端的IP地址的入站規則，然后才能連接到云上服務器上，這種情況不僅增加了密鑰管理的難度，同時對于只存在私有網絡中的服務器且本地數據中心和云上環境沒有互聯的場景是一個很大的挑戰。通過ec2-instance-connect服務特性并結合Session Manager可以方便的滿足客戶通過SSH訪問云上EC2的情景。

將以上代碼中的Step1到Step3編寫成一個腳本，在每次執行ssh之前，先運行該腳本，確保新生成的SSH Key有效（通過send-ssh-public-key上傳到EC2上的Key有效期只有60s）。

注意：如果使用動態生成SSH Key的方式，需要先創建“EC2 Instance Connect Endpoint”，同時確保本地電腦上使用的IAM角色包含有“ec2-instance-connect:SendSSHPublicKey”的權限。另外，亞馬遜云科技中國區暫時不支持該Endpoint類型的創建。

通過本地Session Manager插件SSH進入到堡壘機后，所有的操作都會上傳到S3桶（S3桶名：bastion-audit-log-bucket-，路徑為：logs/）中做持久化存儲。

除通過SSH登錄到堡壘機外，SSM還可以支持SSH Socks Proxy，如下圖在瀏覽器中設置Proxy（以Firefox為例）：

使用以下代碼啟動 SSH Socks Proxy：

啟動后，就可以通過Socks Proxy訪問內網的WebServer。

未來架構演進

本方案中堡壘機是根據最常用的功能，如端口轉發、SSH訪問來設計的，但在一些特定的場景中，還需要設計更多復雜的堡壘機方案，如：Windows類型的堡壘機支持、如何使用IAM角色對堡壘機權限進行更精細化的管理等，這些都是未來本方案演進和增強的一個方向。目前我們方案中，創建的堡壘機類型只有一種，任何擁有啟動Session Manager的IAM用戶/角色都可以去訪問它并進行操作，但在一些場景下，客戶需要對于不同的角色使用不同的堡壘機：如角色A僅可以訪問堡壘機A，并通過該堡壘機上賦予的IAM權限進行相應的操作；角色B僅可以訪問堡壘機B，通過該堡壘機上賦予的IAM權限進行相應的操作。不同的用戶角色和客戶自有的AD域控進行集成，可以靈活的進行更精細化的權限控制。

總結

本文主要介紹了基于Amazon Systems Manager Session Manager的堡壘機的設計和實現，并通過IaC自動化方式構建和部署云上堡壘機，同時基于堡壘機的使用場景進行了舉例，介紹了不同場景下堡壘機的使用方法和步驟。該堡壘機方案已經集成到Cloud Foundations快速啟動包服務中，為企業用戶提供更便捷的部署方式。

在安全方面做的同樣出色的亞馬遜云科技Amazon Lightsail和亞馬遜云科技Amazon CodeWhisperer也非常實用。

亞馬遜云科技Amazon Lightsail可以在Amazon EC2上拓展和遷移，其安全性背靠亞馬遜云科技。亞馬遜云科技Amazon CodeWhisperer可以對現有的代碼進行實時的檢測，給予一定的建議，所以構建應用程序時更加的安全。對于企業或開發者，亞馬遜云科技Amazon Lightsail和亞馬遜云科技Amazon CodeWhisperer的安全性對工作構建、架構設計等全套工作流都非常重要。

審核編輯 黃宇