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

我們都喜歡想象我們的系統是安全的。 然后…

破！！！

每個開發人員，系統管理員以及最終CISO都面臨著一個非常普遍的噩夢。

必然？

計算機安全的一項基本原則指出， 沒有系統可以達到絕對安全 。 就像人一樣： 沒有人是完美的 。 除非與外界完全隔離，否則不可以。 按照當今的標準，這幾乎是不可能的–此外，擁有一個不能接受輸入和提供輸出的系統的意義何在？

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

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

只要系統是由人制造和操作的，他們就天生就是容易出錯的人，那么它們將永遠不會真正安全。

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

沒有。

見過船的內部嗎？

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

人們通常在設計軟件時采用類似的概念：多個模塊，這樣一個受損害的模塊不會使整個系統癱瘓。

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

減小組件的爆炸半徑 ，從而減小整個系統暴露的沖擊面 。

您可以說是一個安全沙箱 。

那是一個相當不錯的。

PoLP：最小特權原則

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

更正式地說，

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

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

它永遠不會變老

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

這個概念非常簡單：使用底層訪問控制機制來限制“執行單元”可用的權限； 可能是簡單的HTTP服務器/代理，Web服務后端，微服務，容器或無服務器功能。

同時，在沒有服務器的地方……

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

少服務器=省力

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

“稍后再修復權限。”

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

分期將很快遷移到產品。 您的“超權限”功能也將如此。

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

然后是時間的沙土，從每個人的記憶中掩蓋了舊功能。

具有未打補丁的依賴關系和可能有缺陷的邏輯的過時功能，可以完全訪問您的云資源。

無服務器定時炸彈 ，如果有的話。

再次！

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

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

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

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

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

整個層次結構最終歸結為一組權限，每個權限采用一種相當簡單的格式 ：

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

用英語，這僅意味著：

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

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

現在來看一些例子。

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

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

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

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

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

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

現在是銀彈 ：

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

是的，您可以自己對AWS賬戶中的任何 內容 執行任何操作。

有點像AdministratorAccess受管策略。

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

無服務器的安全夢night。 不用說。

不惜一切代價避免。

期。

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

那有多難？

需要注意的是，您必須對該計算單元中的每個單個操作執行此操作（例如lambda）。 每一個。

當您需要配置事件源來觸發這些單元時，情況會變得更糟。

假設，對于API網關觸發的 lambda，必須授予API網關服務在特定APIG端點范圍內（使用CloudFormation 語法 ）調用您的lambda的權限：

{"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"} }

或對于由Kinesis流提供動力的 lambda，在這種情況下情況會變得更加復雜： Lambda函數需要訪問以觀看和從流中拉出 ，而Kinesis服務也需要獲得許可才能觸發 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"}}

因此，您將看到，這種粒度帶來了強大的力量和巨大的責任感 。 一個丟失的權限（heck，一個錯誤鍵入的字母），它是403 AccessDeniedException 。

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

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

是的，是的。 如果您手動進行 。

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

幸運的是，如果您已經開始自動化，則有很多選擇：

如果您在使用著名的無服務器架構 -這意味著你已經涵蓋在扳機上的權限前-還有的serverless-puresec-cli從插件Puresec 。

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

AWS圣杯：來自眾神

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

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

選擇SLAppForge Sigma

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

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

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

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

（如果您有其他涼爽的無服務器安全策略生成工具，請在下面發表評論！不， AWS Policy Generator不算在內。）

在結束時

最低特權原則對于無服務器安全和軟件設計至關重要。 遲早會節省您的時間。 Lambda的高度精細的IAM許可模型非常適合PoLP。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。