在您的組織中延伸安全主事者精神

Clarke：(00:05)
Megan，非常感謝您參加我們今天的談論。

Megan：(00:07)
是的，當然。

Clarke：(00:08)
您能否說說您的相關背景，以及您是如何來到 AWS 的？

Megan：(00:13)
15 年來，我從事過不同的安全相關職位，最初是在一間醫院擔任網路安全專員。之後加入一間總部位於西雅圖的全球零售商，並從事不同的安全工程和架構相關職位。實際上，我們在 2014 年成為 AWS 的客戶，我協助制定了雲端安全策略，並在此實作安全控制。然後，我加入 Slalom，成為開發安全營運團隊的一員，協助了北美各地的客戶做同樣的事情，即制定雲端安全策略並實作安全控制。實際上，我作為 Pacific Northwest 的企業解決方案架構師加入了 AWS，之後加入安全專家團隊。

Clarke：(01:02)
太優秀了。

Megan：(01:03)
所以，我來這裡快四年了。是的。

Clarke：(01:04)
真不錯。

Megan：(01:04)
謝謝。

Clarke：(01:05)
所以，我想您起初較專注於您的電腦科學背景。是什麼原因讓您投身安全領域？

Megan：(01:12)
這實際上很有趣。我最初學的是機械工程，我在波音公司實習了三個夏天，與 767-400 線的工具工程師一起工作。我問他們，如果他們現在要就學，他們會學什麼？ 他們告訴我電腦科學。我說，「好吧。」 很震驚，他們都這麼說。所以我說，「好吧，我要上一門電腦安全課或電腦科學課。」 我喜歡這門課。真的很有趣。就像在解謎題，對吧？

Clarke：(01:47)
沒錯。

Megan：(01:47)
班上有一半同學放棄了，因為這不是他們的理想。但我仍然繼續前進。而其中一門選修課是數位安全，這對我來說聽起來很有趣。我上了那門課，被迷住了。我覺得這真的很有趣。只是要解的謎題更多，而且不斷變化。實際上，為取得電腦科學學位，我建置了 IDS 作為我的高階專案。我建置了一個小程式，可以分析網路封包擷取，並判定惡意網路行為。這真的很有趣。

Clarke：(02:21)
太優秀了。顯然，這引導您走向了精彩的職業生涯。

Megan：(02:23)
是的。

Clarke：(02:24)
在 AWS，您是一名資深安全解決方案架構師。那意味著什麼？ 您在該職位中的主要職責是什麼？

Megan：(02:33)
我協助客戶提升 AWS 的安全性。我為他們提供指引，例如如何建置基礎、設定防護機制、實作安全控制，同時協助他們理解「雲端的營運模式是什麼？ 看起來是怎樣的？」 我還指導客戶參加活動、建立研討會、建置人員課程，以及內部領域的工作。我們有一些內部課程，安排有內部實地論文，在安全的各個方面提供指導。協助他們從 100 級安全性提升至 300 級，這樣，他們就能在這些客戶對話中更高效。

Clarke：(03:20)
那麼，Megan，在 AWS，我們擁有非常強大的安全文化，並且我們有很多機制來協助實施這種文化。您有什麼特別喜愛的機制嗎？

Megan：(03:29)
是的，當然。其中一個程序是提交 sev 2。無論您在公司的身分如何，如果您認為存在安全問題，程序是提交工單，叫做 sev 2。另一邊有安全工程師，他將協助評估是否存在問題，並解決問題。而且，如果不是安全問題，也沒有關係。那太棒了。這完善且無究責。確實，我們的想法是，不希望任何人因為認為存在安全問題而感到擔憂或膽怯。我們想要了解問題。我們希望以一種好的方式，以一種積極的方式對問題做出回應。這得到了領導層的支援，真是太好了。我認為，很多時候，只要有安全培訓，並且能夠與自己的領導層交談，每個人都能積極地思考。所以，我認為這孕育了一種圍繞安全的透明文化，以及一種之前從未見過的開放性文化。對此，我真的非常欣賞。

Clarke：(04:44)
沒錯。那麼，當您與整個客戶組織不同級別的客戶交談時，您是否鼓勵他們專注於特定領域，以嘗試培養自己的安全文化？ 又是哪種無究責的安全文化呢？

Megan：(05:01)
是的，當然。可以從幾個方面來看。我往往鼓勵客戶從以下方面考慮其安全團隊的營運：有助於發展業務，能為開發人員提供協助，如果確實有助於讓事情變得簡便，從安全的角度來看是正確的，幾乎是在鋪平道路，這樣如果他們在正確的模式下運作，並且圍繞這些安全要求提供透明度，他們就能加速運作，並且不會遇到大量障礙。我認為，這在安全與發展之間建立了良好的平衡，以便相互之間開展協作。我真的很高興在客戶那裡看到這項工作。我確實在幾個客戶案例中看到過。而且我認為，這對於從安全與開發方面開展合作和互助提供了一種好方法。

Clarke：(06:00)
安全部門並非就是說「不」的部門，而實際上是設法提供幫助並取得成功？

Megan：(06:05)
是的，當然。

Clarke：(06:07)
從客戶領導層角度來看，公司最資深的領導者可以做些什麼，來協助培養我們設法在客戶關係中建立的安全文化？

Megan：(06:20)
我認為，這與傳統的做法有很大不同，對吧？ 負責安全的不僅僅是安全團隊，不可能是這樣。開發人員需要負責的工作很多。實際上，我喜歡向客戶介紹，「嘿，AWS 和客戶之間有共同的責任模型」，但是您可以將所有不同的安全控制，以及雲端安全方面的共同責任模型擴展到您組織的其他部門，並讓每個人知道他們負責什麼。

Clarke：(06:53)
沒錯。

Megan：(06:53)
然後，協助簡化操作，並且讓事情容易做對。實際上，在您自己的組織內部擴展共同的責任模型，對每個人來說都是切實可行的，我認為這是一個非常有效的方法。

Clarke：(07:05)
太優秀了。我敢肯定，您的許多客戶擁有的安全專家，遠遠少於他們希望擁有的數量。您從哪些方面可以看到，安全團隊能夠將其關注點和影響力擴展到整個客戶組織的其餘部分？

Megan：(07:22)
是的，從幾個方面可以看到。首先，針對我們要尋找的工作，我們並不總是能找到合適的從業者。所以有時，這意味著稍微拓寬視野並思考，「嘿，如果安全人員不一定了解雲端，但他們感興趣，就讓他們進行嘗試。」 如果您有對安全感興趣，但不一定具有背景的開發人員或 DevOps 人員，請讓他們進行嘗試。提供一些培訓。我認為，有很多工具可以幫助實現。我最喜愛的方式之一是，觀看之前的 re:Invent 影片、re:Inforce，學習 30 分鐘、45 分鐘的安全基礎最佳實務課程。很多專門針對客戶製作的影片，都提供了客戶如何實作的絕佳範例，這讓我們跳出思維框架，我認為這真的很有幫助。此外，獲得 AWS 解決方案架構師助理級或專業級認證，也是學習這些基本概念真正有效的好方法。當然，安全專家認證非常好。

Clarke：(08:39)
過去 18 個月左右，對每個人來說都是艱難的。我們經歷了疫情，更多的人在家辦公。疫情導致人們對雲端的採用是增加還是減少？ 您在客戶身上看到了什麼？

Megan：(08:54)
是的，當然。我見過幾個大客戶不得不增加他們對雲端的採用，來應對剛剛發生的變化。線上零售業務真的爆炸了，因為實體店不得不關閉。我們從中看到了一些有趣的模式。而且，對於其他客戶，我們從中吸取了一些經驗教訓，這取決於他們如何建置初始基礎安全和多帳戶策略。如果他們能夠為此善用自動化，他們就能做得很好，因為他們可以建置更多的帳戶並實作自動化。他們已經建置了自動化來建立這些安全基礎，能夠透過自動化來實作控制。反之，如果未建置自動化，我們有時當然會協助他們在沒有自動化的情況下建置一些，並盡快增加。但是，如果是手動完成，那就太痛苦了，而且速度很慢。所以要確保完成所有這一切...所有這些防護機制，您的多帳戶採用自動化，這些都非常重要。這只是其中一個很好的範例，說明了真實世界如何產生此類影響。當我開始作為 AWS 的客戶時，我們只有兩個開發團隊開始接觸。六個月後，增加到 20 個開發團隊，系統投入生產中，並且其他人都想佈設這個平台。我很早就學習到了這一經驗，我認為很多客戶都必須經歷這一課。

Clarke：(10:31)
因為您到時必須重工，才能真正滿足您想要的安全標準。

Megan：(10:35)
是的，就是這樣。

Clarke：(10:37)
因此，在某種程度上，安全團隊，即客戶帳戶中的安全團隊。是否有一種方法可以為客戶提供通往雲端的道路？

Megan：(10:50)
我想，我已經在客戶那裡看到過這種情況，很多時候安全是最後一個問題。但其實未必如此。如果他們能夠採用在內部部署所採用的安全架構，進行控制並更新以適用雲端，實作一些映射，基本上提前設定這些防護機制，那將會容易得多。他們將為人員進行部署做好準備。而且，如果不需要任何人來推動，那就太好了。可以定義某種指標。可以設定自動化，而無需有人提醒，例如「嘿，我們開始吧。」 而且，我還認為，這為我們提供了機會，讓安全團隊清楚了解安全要求，協助開發人員了解他們需要如何建置，以及安全團隊期望什麼樣的規範。同樣，這可以追溯到開發人員與安全之間的關係發展，只是...這是一種更有效率、更高效的關係，它會協助實現開發人員設法開發的業務功能。

Clarke：(12:10)
沒錯。我能想像，一旦您看到安全團隊在您之前已經進入雲端，您就會建立一定程度的信心和信任，作為開發人員或產品負責人，您會說，「嗯，如果安全團隊正在這樣做，我確實沒有任何藉口了。」

Megan：(12:25)
就是這樣。而且我認為，有一件事非常適合客戶，如果客戶提出這些安全要求並提供範例，就像一個內部 Wiki，例如「安全身分和存取政策是怎樣的？」、「什麼是安全的安全群組，有哪些糟糕之處？」，以及實際有形的範例，那麼這一定會取得很大的成效。這正是我們所談論的。對於存取政策，沒有針對資源之星的行動之星，諸如此類。另一件事是，當安全團隊就位後…如果開發團隊因任何原因而被阻止…例如，如果客戶正在為特定的安全要求而舉步維艱，安全團隊是否可以每週安排工作時間，或者透過 Slack 管道來解決，這確實可讓開發人員的整個程序變得更容易。他們設有協助團隊。很多時候，他們與這些人員建立了友好關係，這樣他們就不必坐在那裡 24 小時被封鎖，或出現類似情形。他們只需透過快速的意見回饋環節來解決問題。也許，這會是「嘿，我們的文件太複雜」或「我們需要指定內容」之類的意見回饋，或者如果我們要求人員在主機上啟動安全代理程式，那麼為什麼不編寫一個程式碼，並在程式碼儲存庫中提供呢？

Clarke：(14:02)
在您剛剛分享的內容中，我還聽到了一些普通安全團隊可能沒有的技能。我們來看一下一些傳統的安全團隊，他們一直在執行 IDS 和不同的網路服務，修補系統，無論在什麼情形下。不過，我剛才聽您說的，如果我錯了，請糾正我，安全團隊現在是否必須真正了解開發週期是如何運作的，甚至如何編寫自己的程式碼？

Megan：(14:33)
是的，當然。我認為，我們不要...依賴於安全從業者的背景，您可能沒有開發人員背景或 CS 學位，這不是必須的，但我認為有一點 Python 程式設計基礎也無妨，而且雲端構建很容易學習。Ansible 只是一個 YAML 組態檔案。我絕對相信，類似於開發團隊的操作只會有所幫助，例如使用包含待辦項目的敏捷實務，產品負責人從安全角度管理優先順序。首先要了解開發人員的工作方式，但實際上這也是一種非常有效的工作方式。當我是一名從業者時，我們就是這樣做的，因為，尤其從安全角度來看，事情變化非常快，業務需求變化也是如此。突然之間，就必須縱向擴展，改變您的營運方式。因此，這有助於您以有規律的節奏，有效地重新確定優先順序，確定應優先安排哪些事項。

Clarke：(15:39)
那麼，是否在組織內部幾乎都執行安全即服務？

Megan：(15:44)
是的，確實如此。

Clarke：(15:46)
真不錯。我們稍微轉換一下話題，關注最近新聞中的一些事情。關於勒索軟體，即便沒有特別關注，也會聽到一個接一個的勒索軟體事件。您從客戶那裡看到了哪些事件，您在降低勒索軟體風險的技術方面向他們提供了什麼樣的建議？

Megan：(16:11)
在過去兩個月裡，我可能與客戶直接就勒索軟體進行了 20 多次對話。而且，我喜歡進行這些對話，因為這就像是，「嘿，我們想要了解 AWS 的看法是什麼。」 這只是在告訴我，他們認為我們是合作夥伴，這太棒了。所以，通常情況下，我所做的是採用 10 項最佳實務，因為並沒有針對勒索軟體的靈丹妙藥。您確實必須擁有強大的安全程式、強大的安全控制，並確保其有效執行。但肯定有一些關鍵領域需要覆蓋，所以我們介紹多帳戶策略、最低權限存取。我真正關注的一個領域是，是否在任何地方都有靜態、長期有效的 IM 憑證？ 如果您這樣做了，可以用放大檢視有哪些並確定最重要的一項，是否仍需要在那裡？ 我們是否可以重新架構？ 如果真的需要（因為在某些情況下需要混合存取，它們是必需的），我們會盡量減少連接至該憑證的存取權，這樣就可以在環境中執行很少的操作，然後監控使用其使用狀況並將其作為一項風險。記錄在風險登記冊上。請勿放任不管。如果將來有機會擺脫，那就擺脫它。這往往是我們看到的最大風險之一，我們希望確保能夠積極主動地協助客戶避免糟糕的情況。

Clarke：(17:44)
而且，據我了解，降低勒索軟體風險實際上只是很好地實作安全基礎措施。這樣陳述正確嗎？

Megan：(17:52)
就是這樣。修補並不是一個新概念。實際上，您可以在 AWS 中以多種不同的方式執行此操作。您可以使用 Auto Scaling 群組進行擷取和取代，並從 CICD 管道重新啟動系統。您可以使用 Systems Manager。從這一點來說，Systems Manager 就像一半是操作，一半是安全工具。它能夠做的事情令人驚歎。是的。選項非常多。我們也會談論選項。客戶還問了我一個問題，我認為這是很好的對話，「嘿，我們曾經透過內部部署進行實體隔離斷網備份。我們實際上有磁帶備份，把它們放在一輛鐵山卡車上，這樣任何人都無法觸及這些備份。在 AWS 中是如何做到的？」 好吧，只需 API 即可操作一切，這是連接在一起的，但如果您將安全、安全邊界視為 AWS 帳戶，則可以建立單獨的帳戶…並將您的備份傳送至該帳戶。您可以使用推拉式機制來進行自動化，以便擁有一個可用於備份的登陸帳戶。然後，建立一個單獨的帳戶，您可以在這裡從已知的良好來源提取資訊，並且可以使用 S3 物件區塊之類的物件，採用一次性寫入，讀取 S3 儲存貯體上的許多蠕蟲，以及使用一些非常強大的安全和控制功能，甚至盡量減少帳戶管理員的存取權。然後使用 AWS Backup，剛剛宣佈推出，我想是在兩週前，或者就在最近，AWS Backup Vault Lock 可讓您執行類似操作，一次寫入，多次讀取，套用至保存庫。所以，基本上，這樣做會阻止您在完成後對這些備份進行變更。您無法刪除任何內容。有了 AWS Backup Vault Lock，您可以設定政策、存取政策，以及阻止人員對其做出任何變更。它本質上類似於 S3 物件區塊，因為資料存放在那裡，在一段時間內是禁止使用的。

Clarke：(20:05)
原來如此。除了您提到的一些工具和最佳實務之外，還沒有提到的一件事是事件回應準備。這有多重要，客戶在該領域應該做些什麼？

Megan：(20:19)
我們在專門討論這些勒索軟體時，我總是問客戶，「您真的做過勒索軟體安全事件的模擬演練嗎？」 因為，模擬演練非常重要。如果您從未從事過事件回應工作，那可能會壓力很大。透過模擬演練，您有機會解決在實際事件中不需要處理的許多問題，這種情況下，您只想集中精力並且毫無問題地開展調查。在模擬演練中，我們可以了解演練的本質，即如何知道發生了事件？ 我們是否可以存取我們的所有 AWS 帳戶，來進行所需的調查？ 在哪裡可以看到事件？ 是否透過我們的安全營運中心？ 是否編製了一本手冊，其中概述這些人員需要做的所有活動，以便他們能夠一致地做出回應，並擁有做出這些決定所需的資料？ 然後，我們是否引入了相應的利害關係人？ 因為如果確實發生安全事件，我們需要知道如何與我們的客戶以及他們的客戶進行溝通。而且，不僅僅在這方面解決了很多問題，我們的專業服務團隊也可以進來協助客戶。我們已經進行了多次，熟能生巧，對吧？ 所以，每當對某種場景感到擔憂時，只需說，「好吧，演練一下。」 就不會覺得那麼可怕了。只需演練一下，就能做出改善，就這麼簡單。

Clarke：(21:55)
您提到了其他利害關係人。這不僅僅是安全團隊的演練嗎？

Megan：(22:00)
是的，肯定不是。

Clarke：(22:01)
還有哪些其他利害關係人應參與這些桌面演練呢？

Megan：(22:06)
是的。法務部門當然通常會參與進來，通常還有隱私權團隊、安全管理，視乎演練的類型，正在演練的事件，可能還包括服務台，也可能包括應用程式和開發團隊，以協助了解我們是否要進行任何類型的風險降低。這會對下游產生什麼影響？

Clarke：(22:36)
我的意思是，客戶階層的所有級別都參與了嗎？ 執行長會參加這些桌面演練嗎？ 或者還有哪些級別？ 在哪裡停止？

Megan：(22:50)
是的。我認為，想要參與並且需要了解該程序的人員都可以，因為實際要進行安全事件演練時，通常是保密的。您要確保只有相應的人員知道，以及了解須知事項，以便以一種有計畫的方式進行溝通。但是對於演練，沒有理由不讓想要參與的人員參與進來。而且，如果執行長感興趣，絕對要讓他加入。

Clarke：(23:21)
太棒了。

Megan：(23:22)
每個人都能從中學到一些經驗。

Clarke：(23:24)
最近的新聞中有另一個重要主題，並且客戶一直在詢問的是零信任概念。零信任對您意味著什麼？

Megan：(23:34)
是的。傳統上，為了針對我們的環境進行存取和安全控制，我們很大程度上依賴網路界限。而今天，我們要做的實際上是在 API 層，對呼叫進行身分驗證和授權。因此，這意味著，無論是使用者存取我們的環境，還是 API 對 API 呼叫，我們都希望確保其在網路通訊路徑中的每個步驟都經過身分驗證和授權。

Clarke：(24:10)
Megan，非常感謝您參加我們今天的討論。

Megan：(24:12)
是的。謝謝。這真的很有趣。