該問題與Disable AWS Lambda Environment Variables在總體用途上有一些相似之處，但主要針對網絡訪問。如何保證提供數據的aws lambda調用者保持安全
我想提供第三方調用我的Lambda函數的功能。第三方將自己的數據提交給Lambda函數（通過有效載荷，或通過指定數據位置，例如S3存儲桶）。
我希望Lambda服務能夠保證第三方所提供的數據沒有從Lambda流程泄漏到其他任何地方。爲了做到這一點，至少第三方必須保證Lambda函數沒有連接到互聯網上的其他資源並將數據泄露給它。
假設
有沒有什麼辦法可以通過Lambda實現這一點（可能與其他AWS產品結合）？我已經研究了使用網關，EC2，靜態加密，S3和所有這些定製權限的解決方案，但沒有找到解決方案。
您可以在VPC內部創建lambda方法並確保其安全。 閱讀本https://forums.aws.amazon.com/thread.jspa?messageID=733719 他們有問題，因爲他們無法訪問互聯網
唯一的「證據」，你可以提供將是一個外部可信的第三方（不AWS）的形式，其審計您的環境，做法和政策，並確保您滿意地確信您能夠正確處理敏感數據。
客戶端是–無論出於何種原因–不願意相信你能處理他們的數據，而同時也略讀它的一些未經授權......同時你可能不想簡單地許可你的代碼，以便它們可以運行它在一個對他們的滿意度安全的環境中。
這些都不是技術問題。這些都是信任問題。
我不完全相信你已經考慮過一個真正孤立的環境究竟意味着什麼。顯然你不能查閱任何數據庫......但是，它也必然會被剝奪任何日誌功能。 console.log(data.super_secret);。來自Lambda函數的日誌將離開Lambda環境並飛往CloudWatch。
假設無論出於何種原因你仍然不服氣，總是有DNS Tunneling。這個邪惡計劃的美妙之處在於，即使您沒有互聯網，您也絕不會與VPC中的DNS解析無關。 169.254.169.253處的DNS解析器始終存在，有助於偵聽，不受安全組限制，不受網絡ACL限制，不受默認路由影響。你想偷偷從一個「孤立」的環境中走私數據？完成。
在任何情況下，AWS不作保證，以配置的安全性 - 他們只承擔保護其基礎設施本身的責任。他們向你保證它和你配置的一樣安全......但你如何配置它取決於你。他們把它叫做共享安全模型：
雖然AWS管理的安全雲，安全在雲是客戶的責任。客戶保留對他們選擇實施的安全措施的控制權，以保護他們自己的內容，平臺，應用程序，系統和網絡，與現場數據中心的應用程序無異。
https://aws.amazon.com/compliance/shared-responsibility-model/
我已經upvoted，因爲你提出了一些有效點（例如console.log）。不過，我不知道爲什麼它是很難理解爲什麼一個客戶不會trust--許多銀行和醫院甚至不信任AWS或谷歌還沒有，所以當銀行和醫院客戶提供敏感數據，它仍然是一個飛躍的信念，假設他們最終會信任AWS/Google/Azure。但這是一個飛躍，因此比其他公司（例如礦山）更容易採取這種飛躍（因此願意做出這樣的假設），而不是那些龐然大物。 – mwag
是的，我明白這是一個信任issue--這個問題的目的是確定是否信任的問題，A和B之間，可與涉及相互信任方的技術解決方案C--類似於如何SSL證書緩解如果沒有可信任的第三方，請使用第三方（證書頒發機構）來代理不可能實現的信任級別。 – mwag
我並不打算說或暗示很難看出客戶爲什麼不信任供應商。 *無論出於何種原因，*旨在爲一切從一個佔位符「廠商似乎粗略」到「客戶端都有自己的數據的實際值的虛高估值」到「變難」和點之間。 –
正如下面的回答指出，一個lambda函數內部VPC如果配置它，使其能夠只能訪問互聯網，但由於*你*控制環境，和*你*控制代碼，這仍然沒有任何目的來「證明」信息沒有泄漏。事實上，除非您無法訪問數據，否則您絕不會向您證明您沒有導出/公開/複製我的數據。否則，如何有一個技術解決方案？唯一可能的「證據」將是可信的第三方審計。 –
我同意你的評估，以下答案由於我對環境的控制而無法解決問題。不過，我不知道是否可信的第三方提供該代碼運行平臺（如果假設它是可信黨始終保持其承諾），以確保爲什麼不能存在的技術解決方案，在該請求調用者，代碼在受限制的環境中運行。 – mwag
順便說一句，我上面的評論，當我說「可信賴的第三方」我的意思是AWS（而不是「第三者」，即提供敏感數據和運行代碼，誰需要數據安全性的保證） – mwag