Ack ：本文是從個(gè)人經(jīng)驗(yàn)以及從無服務(wù)器安全性的其他多個(gè)來源學(xué)到的東西的混合。 我無法在這里列出或確認(rèn)所有這些信息； 但是，應(yīng)該特別感謝The Register ， Hacker Noon ， PureSec以及Serverless Status和Serverless（Cron）icle新聞通訊。

我們都喜歡想象我們的系統(tǒng)是安全的。 然后…

破！！！

每個(gè)開發(fā)人員，系統(tǒng)管理員以及最終CISO都面臨著一個(gè)非常普遍的噩夢。

必然？

計(jì)算機(jī)安全的一項(xiàng)基本原則指出， 沒有系統(tǒng)可以達(dá)到絕對安全 。 就像人一樣： 沒有人是完美的 。 除非與外界完全隔離，否則不可以。 按照當(dāng)今的標(biāo)準(zhǔn)，這幾乎是不可能的–此外，擁有一個(gè)不能接受輸入和提供輸出的系統(tǒng)的意義何在？

無論您采取何種高級安全防護(hù)措施，攻擊者最終都將找到解決方法。 即使您使用具有最大可能密鑰長度的最嚴(yán)格的加密算法，攻擊者最終也會通過蠻力進(jìn)行攻擊。 盡管目前在時(shí)間上是不可行的，但誰能保證一場技術(shù)突破會在明天或第二天成為可能？

但這不是您真正要擔(dān)心的暴力手段： 人為錯(cuò)誤更為常見，并且可能對系統(tǒng)安全性造成破壞性影響； 比暴力破解的密碼要重要得多。 看看這個(gè)故事吧 ，有些人走進(jìn)美國國稅局大樓，and走了數(shù)百萬美元，卻沒有使用任何所謂的“黑客”技術(shù)。

只要系統(tǒng)是由人制造和操作的，他們就天生就是容易出錯(cuò)的人，那么它們將永遠(yuǎn)不會真正安全。

那么，我們注定要失敗嗎？

沒有。

見過船的內(nèi)部嗎？

它的船體如何劃分成多個(gè)艙室，這樣一個(gè)泄漏的艙室不會導(dǎo)致整艘船沉沒？

人們通常在設(shè)計(jì)軟件時(shí)采用類似的概念：多個(gè)模塊，這樣一個(gè)受損害的模塊不會使整個(gè)系統(tǒng)癱瘓。

結(jié)合最小特權(quán)原則 ，這意味著組件將損害最小程度的安全性-理想情況下，攻擊者將只能在模塊安全范圍的范圍內(nèi)造成破壞，而永遠(yuǎn)不會超出范圍。

減小組件的爆炸半徑 ，從而減小整個(gè)系統(tǒng)暴露的沖擊面 。

您可以說是一個(gè)安全沙箱 。

那是一個(gè)相當(dāng)不錯(cuò)的。

PoLP：最小特權(quán)原則

絕對不要給某人（或某物）比他們所需的更多的自由。

更正式地說，

每個(gè)模塊都只能訪問其合法目的所需的信息和資源。 – 維基百科

這樣，如果模塊行為異常（或被具有惡意惡意的實(shí)體（ 黑客 ，英語）強(qiáng)迫行為），則可將其可能造成的危害降到最低； 沒有采取任何預(yù)防性的“行動”，甚至在確定“違反”之前！

它永遠(yuǎn)不會變老

盡管該原則最初是在遺留系統(tǒng)的上下文中提出的，但它更適用于“現(xiàn)代”架構(gòu)。 SOA（嗯，也許不是那么“現(xiàn)代”），微服務(wù)和FaaS（無服務(wù)器功能，因此也就是無服務(wù)器安全性）。

這個(gè)概念非常簡單：使用底層訪問控制機(jī)制來限制“執(zhí)行單元”可用的權(quán)限； 可能是簡單的HTTP服務(wù)器/代理，Web服務(wù)后端，微服務(wù)，容器或無服務(wù)器功能。

同時(shí)，在沒有服務(wù)器的地方……

隨著無服務(wù)器技術(shù)在全球范圍內(nèi)的廣泛采用 ，無服務(wù)器安全性的重要性以及我們PoLP的價(jià)值變得比以往更加明顯 。

少服務(wù)器=省力

無需配置和管理服務(wù)器（環(huán)境）意味著無服務(wù)器開發(fā)可以以驚人的速度進(jìn)行。 有了CI / CD，這只是代碼，提交和推送的問題； 幾分鐘之內(nèi)，一切就可以啟動并運(yùn)行，即使不是幾秒鐘。 沒有SSH登錄，文件上載，配置同步，服務(wù)重啟，路由更改或與傳統(tǒng)部署相關(guān)的任何其他討厭的瑣事。

“稍后再修復(fù)權(quán)限。”

las，在那些“無ops”開發(fā)人員（如我自己）中，這是很常見的事情。 您急于將最新的更新推送到暫存中，而避免過多“拒絕權(quán)限”錯(cuò)誤的“簡便方法”是放寬對FaaS實(shí)體（ AWS Lambda ， Azure Function等）的權(quán)限。

分期將很快遷移到產(chǎn)品。 您的“超權(quán)限”功能也將如此。

它會留在那里。 遠(yuǎn)遠(yuǎn)超出您的想象。 最終，您會將流量轉(zhuǎn)移到更新版本，而保留舊版本不變。 以免破壞其他一些依賴組件，以防您踩到它。

然后是時(shí)間的沙土，從每個(gè)人的記憶中掩蓋了舊功能。

具有未打補(bǔ)丁的依賴關(guān)系和可能有缺陷的邏輯的過時(shí)功能，可以完全訪問您的云資源。

無服務(wù)器定時(shí)炸彈 ，如果有的話。

再次！

如果我們從分階段部署開始就遵循最小特權(quán)原則，它將大大減小爆炸半徑：通過限制允許執(zhí)行的功能，如果系統(tǒng)的其余部分受到“利用的程度”，我們將自動對其進(jìn)行限制控制曾經(jīng)落入錯(cuò)誤的手中。

完善無服務(wù)器安全性：在公共云平臺上

這些事情說起來容易做起來難。

目前，在公共云FaaS技術(shù)的領(lǐng)導(dǎo)者中，只有AWS具有足夠靈活的無服務(wù)器安全模型。 GCP會自動為給定項(xiàng)目中的所有功能分配一個(gè)默認(rèn)的項(xiàng)目級Cloud Platform服務(wù)帳戶 ，這意味著就安全性和訪問控制而言，所有功能都將歸于一攬子。 Azure的IAM模型看起來更有希望 ，但是它仍然缺少諸如AWS和GCP中可用的基于角色的自動運(yùn)行時(shí)憑據(jù)自動分配之類的炫酷功能。

AWS已為其Lambda函數(shù)應(yīng)用了自己的基于IAM角色的權(quán)限模型 ，從而使用戶可以靈活地為每個(gè)Lambda函數(shù)定義具有完全可自定義權(quán)限的自定義IAM角色（具有完全可自定義的權(quán)限）。 它具有令人印象深刻的一系列預(yù)定義角色 ，您可以在這些角色上進(jìn)行擴(kuò)展，并且具有定義明確的策略，用于對資源或主體類別進(jìn)行權(quán)限范圍界定，合并引用同一組資源或操作的規(guī)則等。

整個(gè)層次結(jié)構(gòu)最終歸結(jié)為一組權(quán)限，每個(gè)權(quán)限采用一種相當(dāng)簡單的格式 ：

{"Effect": "Allow|Deny","Action": "API operation matcher (pattern), or array of them","Resource": "entity matcher (pattern), or array of them" }

用英語，這僅意味著：

允許 （或拒絕 ）擁有此權(quán)限的實(shí)體（用戶，EC2實(shí)例，lambda；無論如何）對匹配的資源執(zhí)行匹配的API操作。

（也有非必填字段“ Principal和“ Condition ”，但為簡潔起見，在此將其跳過。）

現(xiàn)在來看一些例子。

{"Effect": "Allow","Action": "s3:PutObject","Resource": "arn:aws:s3:::my-awesome-bucket/*" }

這允許受讓人將一個(gè)對象（ s3:PutObject ）放入名為my-awesome-bucket 。

{"Effect": "Allow","Action": "s3:PutObject","Resource": "arn:aws:s3:::my-awesome-*" }

這是相似的，但是允許在名稱以my-awesome-開頭的任何存儲桶上執(zhí)行my-awesome- 。

{"Effect": "Allow","Action": "s3:*","Resource": "*" }

這允許受讓人針對其擁有的AWS賬戶中的任何存儲桶執(zhí)行任何 S3操作（獲取/放置對象，刪除對象，甚至刪除存儲桶 ）。

現(xiàn)在是銀彈 ：

{"Effect": "Allow","Action": "*","Resource": "*" }

是的，您可以自己對AWS賬戶中的任何 內(nèi)容 執(zhí)行任何操作。

有點(diǎn)像AdministratorAccess受管策略。

而且，如果您的委托人（例如lambda）受到威脅，攻擊者實(shí)際上就可以對您的AWS賬戶進(jìn)行管理員訪問！

無服務(wù)器的安全夢night。 不用說。

不惜一切代價(jià)避免。

期。

從這個(gè)意義上講，最好的選擇是一系列第一類權(quán)限； 允許范圍最小（限制最大）且涵蓋范圍狹窄且定義明確的范圍。

那有多難？

需要注意的是，您必須對該計(jì)算單元中的每個(gè)單個(gè)操作執(zhí)行此操作（例如lambda）。 每一個(gè)。

當(dāng)您需要配置事件源來觸發(fā)這些單元時(shí)，情況會變得更糟。

假設(shè)，對于API網(wǎng)關(guān)觸發(fā)的 lambda，必須授予API網(wǎng)關(guān)服務(wù)在特定APIG端點(diǎn)范圍內(nèi)（使用CloudFormation 語法 ）調(diào)用您的lambda的權(quán)限：

{"Type": "AWS::Lambda::Permission","Properties": {"Action": "lambda:InvokeFunction","FunctionName": {"Ref": "LambdaFunction"},"SourceArn": {"Fn::Sub": ["arn:aws:execute-api:${AWS::Region}:${AWS::AccountId}:${__ApiId__}/*/${__Method__}${__Path__}",{"__Method__": "POST","__Path__": "/API/resource/path","__ApiId__": {"Ref": "RestApi"}}]},"Principal": "apigateway.amazonaws.com"} }

或?qū)τ谟蒏inesis流提供動力的 lambda，在這種情況下情況會變得更加復(fù)雜： Lambda函數(shù)需要訪問以觀看和從流中拉出 ，而Kinesis服務(wù)也需要獲得許可才能觸發(fā) lambda：

"LambdaFunctionExecutionRole": {"Type": "AWS::IAM::Role","Properties": {"ManagedPolicyArns": ["arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"],"AssumeRolePolicyDocument": {"Version": "2012-10-17","Statement": [{"Action": ["sts:AssumeRole"],"Effect": "Allow","Principal": {"Service": ["lambda.amazonaws.com"]}}]},"Policies": [{"PolicyName": "LambdaPolicy","PolicyDocument": {"Statement": [{"Effect": "Allow","Action": ["kinesis:GetRecords","kinesis:GetShardIterator","kinesis:DescribeStream","kinesis:ListStreams"],"Resource": {"Fn::GetAtt": ["KinesisStream","Arn"]}}]}}]}},"LambdaFunctionKinesisTrigger": {"Type": "AWS::Lambda::EventSourceMapping","Properties": {"BatchSize": 100,"EventSourceArn": {"Fn::GetAtt": ["KinesisStream","Arn"]},"StartingPosition": "TRIM_HORIZON","FunctionName": {"Ref": "LambdaFunction"}}},"KinesisStreamPermission": {"Type": "AWS::Lambda::Permission","Properties": {"Action": "lambda:InvokeFunction","FunctionName": {"Ref": "LambdaFunction"},"SourceArn": {"Fn::GetAtt": ["KinesisStream","Arn"]},"Principal": "kinesis.amazonaws.com"}}

因此，您將看到，這種粒度帶來了強(qiáng)大的力量和巨大的責(zé)任感 。 一個(gè)丟失的權(quán)限（heck，一個(gè)錯(cuò)誤鍵入的字母），它是403 AccessDeniedException 。

沒有簡單的方法； 您只需要跟蹤函數(shù)觸發(fā)或訪問的每個(gè)AWS資源，查找文檔，花些功夫并提供必要的權(quán)限即可。

但是……但是……那是太多的工作！

是的，是的。 如果您手動進(jìn)行 。

但是，這些天誰開車手動？ :)

幸運(yùn)的是，如果您已經(jīng)開始自動化，則有很多選擇：

如果您在使用著名的無服務(wù)器架構(gòu) -這意味著你已經(jīng)涵蓋在扳機(jī)上的權(quán)限前-還有的serverless-puresec-cli從插件Puresec 。

該插件可以靜態(tài)分析您的lambda代碼并生成最小特權(quán)角色。 看起來真的很酷，但是需要注意的是，在每次更改代碼的部署之前，您必須運(yùn)行serverless puresec gen-roles命令。 我還找不到自動運(yùn)行的方法-例如在serverless deploy期間。 更糟糕的是，它只是將生成的角色打印到stdout中。 因此，您必須手動將其復(fù)制粘貼到serverless.yml ，或使用其他伏都教將其實(shí)際注入到部署配置中（希望將來會有所改善：））

AWS圣杯：來自眾神

如果您是Python愛好者， Chalice可以自動為您自動生成權(quán)限。 圣杯在很多方面都很棒。 超快速部署，注釋驅(qū)動的觸發(fā)器，需要維護(hù)的配置很少甚至沒有，等等。

但是，盡管是從AWS眾神直接獲得的幫助，但它似乎在權(quán)限方面錯(cuò)過了“最小”一詞； 如果您有列出某些存儲桶foo 內(nèi)容的代碼，它將生成權(quán)限以列出AWS賬戶中所有存儲桶的內(nèi)容（ "Resource": "*"而不是"Resource": "arn:aws:s3:::foo/*" ），而不僅僅是您感興趣的存儲桶。不酷！

選擇SLAppForge Sigma

如果您是初學(xué)者，或者不喜歡CLI工具，那么SLAppForge中提供了Sigma 。

作為成熟的瀏覽器IDE，Sigma會在您編寫（鍵入或拖放 ）代碼時(shí)自動分析您的代碼，并為Lambda運(yùn)行時(shí)和觸發(fā)器獲取必要的權(quán)限，因此您已全面了解。 最近引入的權(quán)限管理器還允許您根據(jù)需要修改這些自動生成的權(quán)限。 例如，如果您正在集成Sigma尚不了解的新AWS服務(wù)/運(yùn)營。

另外，有了Sigma，您無需擔(dān)心任何其他配置。 資源配置，觸發(fā)器映射，實(shí)體相互關(guān)系等-IDE會處理所有這些。

需要注意的是，Sigma目前僅支持NodeJS。 但是Python，Java和其他很酷的語言正在興起！

（如果您有其他涼爽的無服務(wù)器安全策略生成工具，請?jiān)谙旅姘l(fā)表評論！不， AWS Policy Generator不算在內(nèi)。）

在結(jié)束時(shí)

最低特權(quán)原則對于無服務(wù)器安全和軟件設(shè)計(jì)至關(guān)重要。 遲早會節(jié)省您的時(shí)間。 Lambda的高度精細(xì)的IAM許可模型非常適合PoLP。

Puresec CLI插件 ，多合一Sigma IDE和AWS Chalice等工具可以自動生成安全策略。 使您的生活更輕松，同時(shí)仍然遵守PoLP的承諾。

翻譯自: https://www.javacodegeeks.com/2018/11/serverless-security-putting-autopilot.html

總結(jié)

以上是生活随笔為你收集整理的无服务器安全性：将其置于自动驾驶仪上的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。