提升 AWS 及其他領域的安全標準

Clarke (10:27)：
我會設想所有從事 AWS 安全工作的開發人員不一定都具有堅實的安全工程背景。您制定了哪些類型的機制，以便這些開發人員能達到您為 AWS 安全設定的標準？ 尤其是在建置人員工具中，甚至可能是面向客戶的安全產品中？

Eric (10:50)：
是的，考慮這個問題的方式有多種。一方面，Amazon 的安全是建置人員的準則。我們無法完成所有我們需要做的事情。如果我們僅僅透過在團隊中新增工程師來擴大業務，那麼我們就無法擴展業務。因此，我們所做的大量工作便是建置工具。這是直接的軟體開發，就像您在 Amazon 任何其他團隊所做的一樣，只是您正在建置安全工具。因此，我們的許多工程師都不是安全工程師，他們並沒有安全背景。他們不需要具備任何特定的安全專業知識即可加入團隊。他們中的一些人對安全充滿熱情，其中一些人只是喜歡這份工作及他們共事的團隊，他們喜歡做現在正在做的事情，但他們對安全並沒有特別感興趣，這樣也行。

Eric (11:37)：
整個安全領域在於弄清楚某些建置人員做了什麼假設，然後弄清楚如何違反這些假設以將系統推入非預期的狀態。當我將整個硬碟的數據塞入該欄位時會如何？ 當我提高到 11 時會如何？ 當我在該欄位中輸入負數時會如何？ 根據我的經驗，這種思維方式往往是天生自帶的，而且很難予以教授。

Eric (12:18)：
因此，當我們找到具有這種思維方式的人時，可以教授所有特定的安全知識、所有日常技術，而且我們可以非常輕鬆地就讓人們加深對其的了解。我上大學時每天的日常事項已不復存在，而我在大學裡學到的基礎知識仍然適用，不過並沒有任何特定的技術適用。因此，我們實際上有一個非常強大的計劃，來增加具備特定安全通口的人員。

Eric (12:46)：
所以，您的問題有兩個答案。有一群人我們不需要增強他們的安全性。這是一個標準的開發任務。這是一個標準的建置人員角色。他們擅長於此。他們中的一些人確實表達了對安全的興趣，這很好，我們也鼓勵這樣做。但這不並非必要的。然後在另一方面，我們找到了那些傾向於弄清楚我會如何破壞事物的人？ 並詢問：「我會如何破壞事物？」，進而自然會引致：「我該如何進行修復，以免它們再次遭到破壞？」 此處涉及的所有任務特定技能，我們都會進行教授。

Clarke (14:03)：
所以，到那時，或者我猜想與這一點相反，我們的許多客戶，當他們試圖在自己的開發社群中建立安全專業知識時，他們採取的其中一個途徑是：他們將聘用安全專家並將他們安排在一個「常規開發團隊」中，以幫助在該團隊內建立安全標準，並且基本上具有「安全擁護者」的思維方式。因此，我們的想法是我們擁有的安全專業人員數量有限，因此我們嘗試將他們分散到各個開發團隊中，這樣一來，所有團隊都能順利開展工作。在 AWS 和 Amazon 是否有類似的情況，我們如何看待它們，或者由於安全已植根於我們的骨髓中，每個人都意識到，「我對我的應用程式的安全性負有一定的責任，因此，我將遵循流程行事」？ 您能否簡單談談這是如何運作的嗎？

Eric (14:58)：
好的。安全性是首要目標。我們基本上都相信，就像可擴展性、可用性、低延遲、低抖動一樣，安全性是客戶體驗的一部分。它我們所建置的一切功能的一部分。也就是說，安全專業知識並不常見。我們的安全工程師人數並未達到我們預期的數量。我的意思是，如果我們的每位開發人員都是安全專家，那我會非常開心。我並不以為然。所以，我認為您使用「安全擁護者」這個詞很有趣，因為這實際上是我們內部計劃的名稱，我們在服務團隊中發現有安全意識的員工，我們為他們提供培訓和支援，幫助他們提高自身的安全技能，以便他們能夠對整個服務團隊起到積極影響。

Eric (16:38)：
然後當有重大決策時，他們不必採取孤獨的態度說：「作為這裡唯一的安全擁護者，我覺得其並未做好準備，尚不能發佈，或者我們需要做一些額外的工作。」 他們可以利用整個安全組織，而我們可以基於客戶至上的原則攜手合作，找出什麼最適合客戶的解決方案。如果我們提供不安全的服務，這對客戶來說就是錯誤的結果，但如果我們不提供服務...就像一項不存在的服務，根本就無法取悅客戶，所以我們必須取得適當的平衡。透過在服務團隊中內嵌安全專業知識，與服務團隊深度共情，然後 AWS 安全團隊中的安全專業知識仍對服務團隊提供支援，但我們更多地是承擔稽核員的角色，從而更快做出了更好的決策。

Clarke (17:28)：
我想這會減輕...同樣，在我與許多客戶對話中，安全部門常常被視為拒絕部門，或者是我需要避免的部門，因為這樣才能發佈我的應用程式。根據我們的案例所示，使用您剛才談到的這種模型，信任的橋樑似乎得到了擴展，每個人都意識到，「嗯，安全就是工作的一部分，這就是我們在 Amazon 做事的方式」。然後，最終結果是推出了更安全的產品。
 
Eric (18:00)：
所以，不久前，我們試圖提出一個使命宣言。就像您說的，AWS 安全是做什麼的？ 我們想出的最好的定義是安全運送。這是兩個詞，我認為它很好地說明了我們存在的原因。該公司的存在並非是為了提供安全方案。其名為 Amazon Web Services 而非 Amazon Security。因此，我們在此向客戶運送以提供這些網路服務。如果我們不運送，我們就沒有在執行。我們並未做企業應做之事。所以，我們在此是為了實現業務。我們並不是開展業務的理由。如果沒有絕佳的安全性，就無法開展這項業務，但我們只是業務的一個方面。
 
Eric (18:44)：
對我們來說，最重要的是我們獲得的高層支持。顯然，安全性非常重要，而且是自上而下傳遞的。所以，因為我們不是說，「我們是安全團隊，您必須聽我們的。拜託，請注意...」 我沒有這種問題。從執行長開始，便已奠定基調。每個人都知道安全很重要。
 
Clarke (20:04)：
感謝您。那麼，在衡量安全計劃時，特別是針對在 AWS 中編寫程式碼的開發人員和其他人員，您會使用哪些關鍵指標來衡量整個 AWS 開發社群中安全計劃的有效性？
 
Eric (20:57)：
我們有兩個地方要套用指標。
 
Eric (21:43)：
您不想衡量關閉票證的時間。票證所需的時間與關閉票證的時間一樣長。不過，我們要衡量的是我們的回應能力。因此，我們在首次參與時制定了 SLA。例如，如果您向 AWS-security 傳送電子郵件，我們已公開聲明您將在 24 小時內收到人工回應。我們對此進行了衡量。實際上，我每週都會查看圖形和圖表，其會顯示「這是我們向傳送電子郵件的人員進行回應的所經過的時間。」 因此，回應能力真的很重要。首先，因為如果您不予回應，那麼您就會失去他人的信任。其次，因為如果您回應迅速，則往往意味著其他好事正在發生。
 
Eric (22:25)：
另一處我們會套用類似思維的是票證失效。
…
所有一切都可歸於票證。因此，我們在票證系統中內建了大量自動化功能，以確保如果票證失效，我們可衡量服務團隊之間的通訊時間和安全團隊之間的通訊時間，因此，我們知道票證何時會失效，我們知道服務團隊何時會阻止我們或我們何時會阻止服務團隊，並且我們可以非常快速地顯示需要立即關注的票證。但這也為我們提供了相關資料以進行自省和反思，並找出我們的哪些流程不起作用，我們需要在哪些地方變更人員配備，我們需要在何處投資更好的工具。因此，我們圍繞安全性來衡量了相關流程，並且我們發現這實際上促成了正確的安全結果。
 
Eric (23:20)：
我們所積極衡量的另一方面，並不是要獲得準確答案。我們在應用程式安全方面花費了大量時間來設計一個好的服務，但 Amazon 從來沒有推出任何產品，並且順其自然。我們不斷新增功能，不斷回應客戶的意見回饋，並且我們的服務會根據這些反饋迅速改變。因此，我們的目標不是安全發佈，而是在服務的整個生命週期內確保安全性，這意味著您在初始應用程式安全審查期間所做的事情很快就會過時並失去其價值。因此，應用程式安全流程的一部分是確定哪些是恆定不變的，哪些有關服務的陳述我們始終希望是正確無誤的，然後弄清楚我們將如何在程式碼中驗證那些變數。
 
Eric (24:10)：
因此，如果服務應該始終拒絕以這種方式格式化的請求，那麼應該有一個金絲雀在生產環境中呼叫該服務，並使用此特別格式化的請求來確保將其拒絕。然後我們會衡量我們的金絲雀。他們覆蓋的服務區域範圍有多大？ 他們執行的頻率為何？ 他們失敗的頻率為何？ 他們獲取得異常結果的頻率為何？ 我們會衡量這些流程，驗證我們的安全狀態。它並非衡量交付的安全性。這很難進行衡量。不過，其衡量的是我們已經建立的安全標準的迴歸。這非常重要，因為總會出現另一個安全問題。我們的團隊具有創新精神，他們不斷推出新的、令人興奮的服務，而這些服務是我們以前從未獲得過的。這是讓我每天堅持前往上班的另一動力。
 
Clarke (26:00)：
這太妙了。因此，在一個相關問題中，但從客戶的角度來看，我們有些客戶非常非常領先，他們正實施基礎設施即程式碼，並透過 CICD 管道投入生產環境。另外，我們有些客戶只會在主控台中進行點按活動。根據我的經驗，我們的大多數客戶都處於中間狀態，即試圖將基礎設施編寫為程式碼 "nirvana"。 您會給客戶領導層提供什麼建議，以真正鼓勵更多地關注工程而不是執行基礎設施的操作點和點按工作？
 
Eric (26:42)：
所以，我從來沒有建置過任何漂亮的東西。我建置了令我無比自豪的事物，在市場上表現良好的事物，而無論是 AWS 服務的公共市場，還是我們服務團隊和其他 Amazon 工作人員的內部市場。但它們都是始於一個想法核心的系統，我們建置了我們認為能夠取悅客戶的最小事物，可以讓客戶滿意，然後我們會盡快對其進行反覆。他們會隨著時間的推移而成長。正是這種反覆為您提供了出色的工具。與他們親近的人認為他們是 Frankenstein 的怪物。就是那堆垃圾，就像所有打包電線和膠帶一樣，看起來像是 MacGyver 製造的。但現實是，它們是很棒的工具。它們非常有效。因為這些是為他們正在執行的任務而建置的，循循漸進，並且他們確實完成了所需完成的任務。
 
Eric (27:42)：
因此，當有人進來時，無論他們是加入團隊還是我們與客戶討論我們如何在內部做事，他們都會看到我們擁有的一系列工具，我們建立的所有這些機制，以及這是壓倒性的。看來我無法進行複製了。首先，您不需要複製。這是為了處理我們特定的安全問題。但是第二，我們確實沒有建立這些事物，我們會不斷實現其成長，而且它們都是從小規模開始發展演變而來的。所以，這就是增量性方法。當我們只是談論指標時，我表示沒有迴歸，並且同一問題無需解決兩次。所以，每天都在往好的方向發展。每天，您都在逐步提高安全標準，並開始呈指數級成長。
 
Clarke (29:34)：
因此，對於正在檢視此內容的客戶，這個想法本質上是從您的工程工作開始，然後慢慢成長並日益對其進行最佳化，而不是我需要一次性變更所有方法？
 
Eric (29:48)：
當然可以。這種漸進式的思維方式總能產生好的結果。而且其必須與另一邊的非 Chicken Little 的安全專業人員進行配對。我們每天都要面臨各種各樣的風險。過馬路會有風險，開車會有風險，將筆記本電腦接入網路也存在風險。因此，我們必須要勇於承擔適當的風險。因此，安全是一門藝術，我希望它更像是一門科學，但是我認為它確實是一門藝術：可用於管理這些風險，了解哪些風險是可以接受的，哪些風險可以緩解，哪些風險可以平息或是不可接受。因此，作為一名安全專業人員，無論在任何崗位，無論在任何不安全的地方，您都必須能夠說出這種風險的嚴重程度。
 
Eric (30:38)：
在安全組織中，當談到安全時，我們一直使用的一個短語是臨床和精確。如果您說，「這是有史以來最嚴重的安全漏洞，我們無法進行修復」，那麼您的信譽將大大受損。您已經關閉了所有討論領域。我們不再就解決方案進行協商談判。您剛剛已將其關閉。反過來，如果您說：「這是一個非常令人擔憂的問題。我擔心這種特定的影響」，這裡有三種可能的解決方案。我喜歡第一個，它雖然價格更貴，但它也提供了這個好處。讓我們談談我們在這裡需要做的事情。它是臨床的，它是精確的，它開啟了對話。我將向您介紹我的專業知識，這樣我們就可以就業務進行對話。因此，建置此安全工具的工程師需要牢記這一點。他們需要思考，「我怎樣才能讓改善業務？」而不是「哦，天哪，一切都勢頭很猛，太可怕了。」