AWS 管理大量帳號時 Bastion 的設計與安全性

2018-12-19 AWS

在整個 104 的 AWS 架構中,各單位擁有自己帳號的管理權 (IAM Admin),自己的帳號自己負責,被罰單懲罰時也自己付錢,看似合理,但若放在整個 Production 的網路結構看時就不是這麼一回事 …

 

問題

 

若是採用 Transit VPC 的架構下,必須要思考的安全性遠遠大於方便性,畢竟大家都是被串在同一個窩,只要其中有一個環節產生漏洞,整個 Production 等同於暴露在風險中。

 

當安全性出現疑慮時,最直接被想到的就是 IAM 跟 Security Group,IAM 可以透過 Policy 的設計避免不當的權限給予,但 Security Group 就比較棘手,尤其是 Bastion 的設定,多數人的家裡 IP 是浮動的,但台灣工程師的奴性就是回家還是會繼續工作,貪圖方便相信很多人都會直接設為 0.0.0.0/0,或者加了當前的浮動 IP 後就忘了拿掉,但實際上你的 IP 已經被別人 reuse。

 

OKAY,那如果有登入 instance 的需求時怎麼辦,總是會有意外需要 Login 進行 Debug 的時候吧?

 

有些人可能會說,用 AWS Config 或其他的 Scan Tool 偵測有沒有不符合規範的 Security Group 啊,不符合就把該 SG 幹掉!

 

沒錯!這是最直接且強硬的作法,但是當人多的時候,這樣的衝擊往往必須接受文化與人的考驗

我當下有緊急的問題要修改啊!

這樣很不方便耶!

我的設備突然被砍掉了,你應該要通知我怎麼做啊!(明明就教過你)

 

解決方案 – AWS SSM (Session Manage)

 

所以當下與團隊的思考後 Bastion 是 AWS 標準方法,但因應企業文化不見得是一個很好的解決方式,後來改採用 AWS Systems Manager 中的 Session Manager

 

2018 年 AWS 針對 SSM 做了許多改進,其中一個亮點就是 Session Manager,其功能就是讓你可以透過 Web Console / CLI 登入 Instance,「用 Session Manager 取代 Bastion」是我們採用的方式,原因不外乎是解決 Security Group 的問題,可透過 IAM 控管可用 Session Manager 的人,Session Manager 下的操作都會被如實的記錄到 S3,整個 Session history 也完整紀錄了 Login Start / End 等資訊。

 

AWS 為了讓 SSM 普及,乾脆 AMI 都直接內建 SSM Agent:

SSM Agent is installed, by default, on the following Amazon EC2 Amazon Machine Images (AMIs):
Windows Server (all SKUs)
Amazon Linux
Amazon Linux 2
Ubuntu Server 16.04
Ubuntu Server 18.04

理論上從 2018 下半年的 AMI 都內建支援 SSM Agent。

 

手動安裝也是簡單到哭,透過 snap 的 app store 安裝 ssm agent:

$ sudo apt update
$ sudo apt install snapd
$ sudo snap install amazon-ssm-agent --classic
amazon-ssm-agent 2.3.274.0 from 'aws' installed

 

如果設備在純 Private 環境的話

 

AWS 大概聽到很多人的心聲,「Configure SSM Agent to Use a Proxy」連純 Private 都設想到了,直接加 HTTP_PROXY 的變數,但 Upstart 的方式比較不建議,因為直接 export 會把整個 network traffic 都指向到 Proxy 去,如果可以還是用 Systemd 比較好!

 

如果 Upstart / Systemd 都不想用,現在 PrivateLink 也支援完整的 Endpoint「Setting Up VPC Endpoints for Systems Manager」,一次會用到四個 VPC Endpoint:

com.amazonaws.region.ssm: The endpoint for the Systems Manager service.
com.amazonaws.region.ec2messages: Systems Manager uses this endpoint to make calls from SSM Agent to the Systems Manager service.
com.amazonaws.region.ec2: If you’re using Systems Manager to create VSS-enabled snapshots, you need to ensure that you have an endpoint to the EC2 service. Without the EC2 endpoint defined, a call to enumerate attached EBS volumes fails, which causes the Systems Manager command to fail. For more information about using Systems Manager to create VSS-enabled snapshots, see Using Run Command to Take VSS-Enabled Snapshots of EBS Volumes.
com.amazonaws.region.ssmmessages: This endpoint is required only if you are connecting to your instances through a secure data channel using Session Manager. For more information.


 

整體來說用 SSM 解決了在安全性的問題,也提供稽核的方式,面對不熟悉的工程師可以直接使用 Web Console,而喜好 CLI 有更好的便利性,實測 CLI 的速度並不輸 SSH terminal (Taiwan -> Tokyo)

給 Mr. 沙先生一點建議

彙整

分類

展開全部 | 收合全部

License

訂閱 Mr. 沙先生 的文章

輸入你的 email 用於訂閱