AWS安全講堂：身份認證秘籍！

嘀嘀~各位云計算界的小伙伴們~

歡迎乘坐AWS安全直通車！

安全直通車

之“AWS身份認證安全”號

安全一直是Amazon Web Services(AWS)的核心主題之一，無論是在云采用框架CAF，還是在Well-architected Framework中。同樣，安全也一直是亞馬遜re:Invent的熱點內(nèi)容，在討論的眾多方面里，AWS身份認證安全是企業(yè)IT部署和運維中要面臨的首要問題。

在這一類事件中，每一個操作者都不是有意為之，每一個攻擊者也不需要很強的技術(shù)。因此，雖然安全技術(shù)很重要，但是比安全技術(shù)更重要的是安全規(guī)范和安全意識。

接下來小編就告訴你2個常見的不規(guī)范操作，各位小伙伴們可要記住避雷喲~

01 把秘鑰上傳到公網(wǎng)，被黑客截取后對賬號進行危險操作。（X）

02 對存儲桶設(shè)置了公網(wǎng)讀寫權(quán)限，導致重要信息的泄露。（X）

身份設(shè)置是使用AWS的基礎(chǔ)，開始使用AWS之前必須要設(shè)置身份認證。本文將歸納總結(jié)如何從身份安全的角度來設(shè)計應(yīng)用架構(gòu)。AWS中的身份認證服務(wù)是AWS Identity and Access Management(AWS IAM)，AWS所有的服務(wù)都會使用AWS IAM來決定如何訪問其他的服務(wù)。因此，有必要對身份的安全最佳實踐進行梳理，發(fā)現(xiàn)并修復(fù)資源、賬戶以及整個組織內(nèi)的權(quán)限問題。通過這些安全檢查，可以優(yōu)化組織的AWS身份，擁有更好的安全性。

圍繞AWS身份認證的安全實踐，主要原則包括以下幾點：

最小權(quán)限原則

避免在Policy的Action和Resource元素中使用通配符，要避免使用寬泛授權(quán)。

使用多個AWS賬號

根據(jù)環(huán)境類型（開發(fā)、測試、生產(chǎn)）等分類創(chuàng)建不同的AWS賬號，這樣就可以清晰地拆分賬單，以及從根本上設(shè)置用戶操作的安全邊界。

創(chuàng)建有意義的

Organizational Unit(OU)結(jié)構(gòu)

當組織創(chuàng)建越來越多的AWS賬號時，就需要使用AWS Organization來管理賬號，通過OU對賬號進行分組。在使用OU對賬號進行分組時，應(yīng)該保證OU能夠反映實際業(yè)務(wù)、環(huán)境，甚至組織架構(gòu)。另外，AWS Control Tower和AWS Landing Zone兩項服務(wù)，可以幫助用戶使用最佳實踐創(chuàng)建AWS賬號結(jié)構(gòu)，并實施初始安全基線。

使用服務(wù)控制策略

(Service Control Policy,SCP)

當認真構(gòu)建了OU層級之后，就可以針對整個組織、OU，或者單獨的成員賬號，設(shè)置SCP，進行賬號層面的權(quán)限管控。

使用聯(lián)合身份認證

如果組織已有企業(yè)目錄，那么建議使用其對AWS賬號進行聯(lián)合身份認證。這樣，就可以避免在云上再單獨維護一份身份清單，并且避免創(chuàng)建長期身份，即IAM User。

使用Role

要使用聯(lián)合身份認證，需要創(chuàng)建Role，以保證聯(lián)合權(quán)限只在Role的過期時間內(nèi)有效。另外，Role應(yīng)該用于運行在AWS環(huán)境上的應(yīng)用的授權(quán)，這樣就不需要創(chuàng)建并分發(fā)長期秘鑰。同時，Role也應(yīng)該用于跨賬號訪問的授權(quán)，避免為第三方應(yīng)用創(chuàng)建組織賬號內(nèi)的長期權(quán)限。

清楚定義信任策略

(Trust Policy)

信任策略定義了誰（Principal）可以使用某個Role。Principal可以是用戶、另一個Role、賬號，或者Identity Provider。當使用Role進行授權(quán)的時候，注意要清楚定義使用Role的Principal，避免使用星號，如sts:assumerole:*。

盡量避免使用長期秘鑰

在必須創(chuàng)建Access Key的情況下要保證密鑰的安全，應(yīng)當遵循如下五點：

1)對Access Key設(shè)置IP白名單授權(quán)，保證只能從授權(quán)的服務(wù)器使用；

2)不要把密鑰硬編碼到代碼里；

3)定時Rotate Access Key；

4)不要以明文發(fā)送Access Key，應(yīng)當加密文件，然后將文件和解密密碼分兩封郵件發(fā)送；

5)不要把Access Key上傳到GitHub等公網(wǎng)環(huán)境。

保證root用戶的安全

除了一些特殊操作之外，永遠不要使用root用戶，尤其不應(yīng)該使用root進行日常的運維操作。同時，在實踐中應(yīng)當遵循：

1)刪除Access Keys；

2)使用SCP限制root權(quán)限；

3)啟用Multi-factor Authentication(MFA)；

4)設(shè)置強密碼，并定期修改密碼；

5)將root用戶郵箱設(shè)置為組郵箱，便于root找回。

保證IAM User安全

如果組織暫時無法使用聯(lián)合身份認證，則需要在AWS創(chuàng)建User，應(yīng)當遵循：

1)創(chuàng)建IAM Group，按照不同的用戶角色對用戶進行分組；

2)設(shè)置強密碼策略，并定期修改密碼；

3)為每個人創(chuàng)建單獨的用戶，不能多人共用User；

4)用戶登錄使用MFA；

5)使用AWS Config審查沒有設(shè)置MFA的用戶；

6)避免為個人用戶創(chuàng)建秘鑰，使用CloudShell。

定期檢查Policy設(shè)置

在最初設(shè)置Policy的時候使用IAM Policy Simulator模擬Policy的權(quán)限，以保證最小權(quán)限。之后使用IAM Access Advisor持續(xù)查看一定時間內(nèi)沒有被訪問過的服務(wù)，然后在SCP中禁用這些服務(wù)。

定期檢查未使用的身份

通過Credential Report檢查一定時間內(nèi)沒有使用過的Identity（Role、Access Key、User），并且將其禁用或者刪除。

定期檢查與第三方賬號

共享的權(quán)限

AWS IAM Access Analyzer支持分析基于資源的策略，例如Amazon S3存儲桶、SQS Queue、IAM角色。這樣，組織就可以識別對資源和數(shù)據(jù)的計劃外訪問，而這種訪問可能會造成安全風險。

設(shè)置審計

對整個組織開啟CloudTrail，并且將CloudTrail日志存儲到單獨賬號，以避免用戶刪除操作記錄。同時，運維人員應(yīng)該熟悉使用Athena等服務(wù)查詢CloudTrail日志的方式。

上述建議從賬號管理到用戶管理，從最小權(quán)限原則到操作審計，都需要認真落實。讓組織內(nèi)每一個人都規(guī)范操作，建立起安全意識，預(yù)防安全事故的出現(xiàn)。聚云科技深知安全的重要性，因此從一開始就會對客戶進行安全培訓，并定期與客戶溝通對配置進行巡檢，保證客戶賬號環(huán)境的安全。

下圖是對如上原則的總結(jié)以及各原則之間的關(guān)系，便于組織進行安全巡檢：