本文最初發佈於gvnshtn.com網站，經原作者授權由InfoQ中文站編譯並分享。
Maersk（馬士基）是全球最大的航運和集裝箱物流綜合公司。我非常榮幸地成爲了他們的身份控制和訪問管理（IAM）主題專家（SME），以及後來的IAM服務負責人。2017年，我和公司其他幾十人一起應對了廣爲人知的notPetya惡意軟件攻擊事件。
這篇文章的目的是分享一些我們的經驗和教訓，以便給後來者參考。攻擊是遲早會發生的，誠然我們有很多先進的裝備，但很多組織從一開始就做錯了。
這個故事涉及2015年到2019年我在Maersk的經歷，其中包括notPetya事件和恢復工作，以及我最後離開前加入控制和保護措施的事情。
2015年
我從2015年初開始在Maersk工作。Maersk歷史悠久，他們的IT部門有一點很有趣，就是他們在整個集團中交付IT服務的方式。當時，這個組織分散爲服務於不同部門（物流、能源、運輸）的多個業務部門。以前，每個業務部門都有自己的IT。但由於Maersk航運公司（運輸業務）是其中最大的，其IT部門自然也最爲強大，並已開始向其他業務部門提供一些共享的IT服務。在經過數年的政治和權力鬥爭後，Maersk的能源業務被出售，公司將資源集中在運輸和物流上。與此同時，IT也逐漸集中化，組織的最高層建立了數字和雲優先戰略。
蜜月
一開始，我參與了一個項目。公司彼時在通過一個著名的身份和訪問管理（IAM）產品將共享的HR系統插入Active Directory，這款產品有一些嚮導式自定義Web服務和數據庫後端服務來方便集成。項目的參與者包括英國和丹麥的同事，橫跨IT、HR等業務部門，IAM技術要素則由微軟提供支持。這個項目持續到2015年底，走過了一場艱辛的旅程。我們的資源有限，但在所有人的努力下解決方案的進展很快。
關係鞏固
Maersk有着令人自豪的歷史，它成績斐然，是很好的工作場所，而這個項目讓我感受到了家的溫暖。上線任務是在幾個週末內完成的，我們花了幾個小時進行了一些真正的冒險，包括在凌晨3點以物理方式“闖入”存在問題的舊服務器！最終，解決方案成功上線，在大約六萬活躍用戶中，我們只錯誤地刪除了一個帳戶。好樣的！
2016年
IAM項目的成功幫我在第一年的績效評估中獲得了最高分，我還參加了微軟Ignite大會，給履歷表又添了漂亮的一筆。
最高特權原則
我在Maersk的工作主要是（現在稱爲）身份驗證和安全項目：身份管理、特權訪問管理、智能卡登錄系統等。IAM系統現在可以處理典型的就職、調職和離職流程，那麼我的下一個任務就是特權訪問管理。在上一個項目中，我發現舊架構普遍不遵循最小特權原則。航運是一項龐大的業務，但利潤相對較低。那時，IT一直被視作成本中心而非業務推動者。安全控制的優先權被高層排在了後面。我們的舊架構有多種安全部門，沒有明確的主管，並且資金有限。
失去機會
那時，我們本可以並且應該一直在應用一致的安全策略來控制帳戶和訪問的。你可以逐步推進變革。你也可以應用新標準併爲它構建服務，然後隨着時間的推移升級更多服務，最後你的舊系統要麼煥然一新，要麼死掉。你獲得的預算越多，流程就越快。一些控制策略的典型例子包括：
- 服務帳戶不應在多個應用程序中使用
- 最終用戶生產力帳戶不應在任何位置具有管理員權限
- 服務器管理員帳戶在工作站上不應具有管理員權限
列表很長，但這只是基本的Microsoft安全基準或分層訪問模型的內容。
在此期間，我們的MSP試圖推銷一款特權訪問管理（PAM）產品，以對用於訪問我們MSP託管系統的MSP憑據進行憑據循環控制；一直以來，我們都在所有Maersk MSP託管的服務器上，將一個充滿所有Maersk和MSP成員的活動目錄（AD）組放入本地管理員組。這還不夠。除了訪問風險（不考慮憑據），那些非MSP託管包該怎麼辦？因此，我也在同時推動IAM解決方案的PAM組件作爲替代方案。
我一廂情願地認爲公司應該用上一些行業水平的東西，但敗在了成本管理政策下，畢竟我的後兜裏沒有幾百萬美元！
2017年
當我在特權訪問項目上四處碰壁時，我們也在同時做其他事情。我們將運營團隊移交給新的供應商；Maersk收購Hamburg Sud時，我們參與了一些有趣的合併活動；郵件自動化正在進行中……生活很美好。
在遙遠的土地上，俄羅斯黑客一直在攻擊烏克蘭。在烏克蘭運營的所有企業通常都使用某款財務應用程序。攻擊者已經黑掉了應用程序的供應商，並將notPetya惡意軟件注入到它的軟件更新中。盡職盡責的財務人員在不知不覺中開門放進了一款破壞力極大的惡意軟件。
notPetya
在2017年6月27日，問題突然爆發！
大約上午10點，我們正在一個玻璃牆會議室開會。外面的人開始躁動起來，可能發生了一些小故障。然後，一些憤怒的人走進來把我們揪出去做事，我們才意識到：辦公室裏的一些工作站似乎掛掉了。不，不僅僅是我們的辦公室。在全球範圍內，所有設備正在逐漸完蛋。服務器呢？域控制器不見了？天哪……幾個小時內，我們就損失慘重。這影響了地球上每臺加入域的Windows筆記本電腦、臺式機、虛擬機和物理服務器。
這家組織剛剛被送回黑暗時代！
災難臨頭，你會怎麼做？對許多人來說，這會是一次滅頂事件。對我們來說，幸運的是，Maersk有很多資源可用。
讓我大開眼界的是，我們甚至都不是目標。至少對我來說，這是一個巨大的驚喜。我一直認爲網絡攻擊在某種程度上是針對性的。但是現代網絡戰極爲殘酷，沒有俘虜。因此不要心存幻想，你可能不相信自己正面臨很大的風險，但你遭受的災難甚至可能與你無關。如果你從互聯網接收數據（當然是對的），那麼最好密切注意所有這些信息。網絡攻擊以前並不罕見，但是在COVID-19時代，私人和國家贊助的網絡攻擊已大大增加。這是做一些基本的防禦行動的最佳時機。也許你很幸運，從未經歷過嚴重的惡意軟件攻擊，但它們隨時都可能來到你面前。攻擊者不在乎範圍，不在乎容量規劃或預算，當然也不在乎你。你需要做好準備！
notPetya惡意軟件很罕見。通常情況下，被惡意軟件入侵時，你會看到設備被加密，並帶有一條消息要求你支付贖金。很多組織（約50％）會屈服，讓這類攻擊更爲猖獗。但notPetya並非如此，沒有人需要付費，它的設計純粹是要搞破壞，也的確達成了目標。
苦藥
在Maersk，之前沒有一致的安全基準。有一些模糊的書面政策，但基本上被忽略了。使用普通生產力帳戶在工作站甚至服務器上執行管理任務的行爲很常見。服務器管理員擁有對大量系統的長期管理訪問權限，即使在我們開始採用雲IaaS的業務裏面管理得更好的部分中也是如此。域管理員不是很多，但它們會被用來在各種設備上執行管理任務。服務帳戶通常會被授予本地管理員組成員資格，而不是適當地委派權限。服務帳戶也會由多個應用程序共享。這些行爲並非Maersk所獨有，在你自己的組織中也很可能很普遍。這些現象是許多（即使不是大多數）組織仍在承擔的風險。
由於notPetya已通過財務軟件包更新找到了立足點，因此notPetya使用常見的憑據傳遞技術在整個組織中水平擴散，並垂直傳播到服務器和域控制器中。由於組織缺乏標準化和一致的特權訪問控制機制，使notPetya得以輕鬆擊潰Maersk。
是的，網絡分段之類的方法將有助於減緩傳播速度。SOC之類的事情將幫助我們在審判日到來之前看到活動。補丁絕對是有幫助的。但是最終，我們未能解決的基本風險是特權訪問的管理機制。
那是不得不嚥下的苦藥。我一直在組織內宣傳的控制機制本可以讓Maersk免受衝擊。但是我敢打賭，並不是只有我對這件事上心了，而且絕對沒人對我指手畫腳。接下來的幾個月，我加入公司以來就一直希望採取的措施都被開了綠燈。真是令人感慨，嚴重的網絡攻擊竟然能推動那麼多事情。
重新立足
在事件發生後的前幾周，一切工作都圍繞着恢復Active Directory展開。問題是Active Directory已在全球範圍內跨數百個域控制器部署，可是災難恢復流程只應對過一個站點或一個數據中心的丟失情況。應急計劃中沒有任何內容寫的是“我們一夜之間就在所有位置失去了一切”。
經過Maersk、微軟和我們合作伙伴的艱苦努力後，我們恢復了目錄服務。這涉及一些源代碼級別的操作，人們帶着各種各樣的數據和設備在世界各地飛來飛去。這段經歷讓我想起了美劇《24小時》，只是沒有緊張的配樂罷了，而且用時顯然不止24小時！
當第一個域控制器恢復時，它是跑在一部Surface Pro4上的。當一切恢復到某種程度的常態時，我們基本上是就把它留在了底座上。
身份驗證服務團隊齊心協力。來自運營、工程、架構師和經理、合作伙伴和供應商……所有人都在緊密合作。然後，我們分成了幾個戰術小隊，在辦公室拐角處用一塊巨大的白板隔開來。爲了完成任務，我們讓人輪班坐在白板旁，對來自業務或其他應用團隊的問題或需求進行分類，而讓其餘團隊成員着手處理當前任務。
目錄本來應該消失了。我敢肯定，大多數組織都會建立一個全新的目錄，但是我們非常幸運，不必一切從頭來過。可是所有這些都是要付出代價的。人們在辦公室喫飯和睡覺，公司預訂了附近每一個酒店房間。人們因爲太累而只能打車上班。對於某些人來說，這種情況持續了數週甚至數月。事件不僅影響了一線人員，還影響了職業生涯、家庭、生活。
你們不會想經歷同樣的災難的。
做事
在我們恢復服務期間，公司四巨頭之一也下來了。高層人員四處奔波，做筆記，參與會議，影響決策。
微軟還提供了出色的領導力，幫助我們快速部署了Privileged Access Workstation（PAW）——特權訪問工作站和Tiered Access Model（TAM）——分層訪問模型。這些技術是微軟網絡安全參考架構（CSRA）的重要功能，組織應對此予以密切關注。而且其成本確實並不是很高。TAM（以及擴展的PAW）更主要是要建立你缺失的流程，提供清晰度、確定界限和設定期望。你可能還需要少量額外設備來處理訪問權限。
這裏的投資收益是不可小覷的。你花的那些錢都會有回報，它們可能阻止了類似攻擊的發生。
重點在於快速行動。找到正確的人授權他們去做事，出錯也可以快速修正。不要浪費漫長的時間討論快要過時的主題，那樣效率太低了。
Windows 10
當時，一項積極的決策是加速Windows 10的部署。在遭受攻擊時，組織已經完成了創建新的Windows 10版本的流程。由於所有工作站都需要重建，自然就用不着回退到Windows 7了。所有設備都被仔細檢查過，而且所有本地管理員特權實例都消失了。
非常好的是我們在客戶端上建立了安全基準。實際上，不再有人會獲得永久管理權限，壓根就不會拿到這種權限。TAM正在融入系統。
具有密碼哈希同步的Azure AD單點登錄
還好我們之前遷移到了帶有密碼哈希同步（PHS）的Azure AD單點登錄（SSO）上。這意味着人們仍然能夠登錄Azure AD並訪問Office365等基於雲的SaaS應用程序！
使用帶有PHS的Azure AD SSO，你可以獲得：
- 對你的身份狀態有更多的保證
- 配置條件訪問規則時的更多選項
- 更好的性能
- 更高的可用性
你可能會擔心這一階段的“密碼哈希同步”。其實，哈希在任何意義上都是不可逆的，並且你不是將密碼存儲在雲中，不是在同步密碼。
恢復正常（計劃延遲了）
我們很快就構建了PAW和TAM的基本骨架。這樣一來，當應用程序開始重新進入環境時，我們就可以發出權威的聲音了：你需要一級管理員ID；不，你不應該使用舊的共享服務帳戶，等等。麻煩的是這些要求必須是領導層給出的，而有時領導層並不那麼重視安全性，他們更想快點恢復業務。這是一場漫長的拉鋸戰。
2018年
下圖是我們討論事情進展時常用的一張圖：
香腸工廠
香腸工廠圖顯示了我們是如何部署TAM的，其中包括工作站、服務器和域控制器的典型三層架構。我們將域控制器和Windows 10資產內置到TAM中，並嵌入所有關聯帳戶。但是，所有要還原的服務器，以及一些虛擬化Windows 7系統仍處於不良狀態。
顯然，我不會討論解決方案的細節，也不會討論其部署方式。但是我確實需要談一些使我措手不及，並最終導致我離開組織的因素。
PAM成爲一件大事
notPetya事件發生時，我是IAM平臺的服務負責人。事件後，高層意識到了“PAM”問題並將其提到了很高的優先級上。組織引入了外部影響力，不幸的是它們還能影響最頂層領導的決策。
計劃
任何安全控制都不是孤立存在的。爲了解決給定的威脅，需要一種分層的方法。美國國家標準技術研究院（NIST）列出了以下五項原則：
識別∙保護∙檢測∙響應∙恢復。
顯然，此次攻擊對Active Directory和加入域的系統影響最大。缺乏一致應用的安全基準和流程是一個很大的漏洞。公平地說，一旦選擇並部署了PAM產品，我們就會盡快保護域管理員、企業管理員等憑據的密鑰。但是就控制而言，光是有工具是不夠的，還要知道它們已經用在了哪些地方，知道哪些地方沒有用上，並能夠對這些情況做出迴應，必須確保你已涵蓋了這五條原則。
我們要建立良好的狀態，然後將系統過渡進來。我們大力發展安全信息和事件管理（SIEM）功能，因此“檢測和響應”原則沒什麼問題。我們在AD中配置各種工件（帳戶、組、組織單位、組策略），然後將系統移入其中並執行應用程序級配置。最後，支持流程將處理其餘的工作。
舊的管理員帳戶還是可以訪問未遷移到TAM中的內容，保留它們純粹是爲了訪問尚未修復的“陳舊”系統，然後在不再需要訪問時將其刪除。
vs現實
我們四大諮詢公司的朋友被催着快點交付。他們有一個在紙面上令人印象深刻的想法——將所有管理帳戶都放到PAM解決方案中。這是有問題的：
- 就算將管理帳戶註冊到PAM解決方案中，它們也仍然可以使用大量資產，它們造成重大損害的能力不會消失。另外，由於舊賬戶數量龐大，這一過程會非常耗時耗力，而且不會有明顯的收益。
- 管理帳戶有許多用例。例如，Maersk（Maersk）是一個啓用雲的組織，其中許多帳戶是在本地創建的，但直到它們同步到雲後纔會供外部開發人員或第三方供應商使用。如果這些人無法訪問PAM控制檯，就沒法幹活了。
可是這個主意得到了高層認可，反對無濟於事。到2018年底，我已經無能爲力。
2019
2019年初，我妻子想要來一場旅行，我請假沒成，最後決定辭職。我設法在離開前向高層傳達我的擔憂，想要最後糾正一些事情，只是這些努力最後都失敗了。於是，我和家人開始了歐洲之旅。
學到東西
你和你的組織可能也有類的經歷。所有類似的攻擊事件背後的原因都差不多。任何組織都不應以自己不會成爲下一個目標爲前提假設。攻擊者明天就可能上門，不要讓他們輕鬆得手。管理和保護你的身份和訪問權限。
對於領導層來說，不要只看同行或中層管理人員的那些美好的故事。坐下與一線員工交流，傾聽他們真實的想法。這將在組織上下建立信任。你需要相信專業人士，而人們則需要相信領導者能夠理解並代表他們。
組織對IT的重視程度越低，相關人員的話語權就越少。IT安全措施是培養員工過程的一部分。聽取員工的意見來幫助和保護他們，保持公開對話。
關鍵在於做出決定並採取行動。決策不必一成不變，事情不一定是完美的。這就是行業現在的運作方式。
無論你處於組織的哪個級別，都可以做一些事情來爲最壞的情況作準備。
做好基礎工作
這可能是全文最重要的部分……
1.少說話，多做事
基礎工作很簡單。設置規則，按照這些規則構建系統，並逐步遷移或淘汰舊系統。但是不要光說不練，見到火星就應該撲滅它。
2.強制執行MFA
爲所有人啓用MFA並強制執行，不要亡羊補牢。在2020年，它是抵禦當今威脅的基本保護措施。那些已有20年曆史的Active Directory密碼策略都是自欺欺人。
3.防止人們使用通用密碼
Azure AD密碼保護是一種簡單的、維護成本較低的方法。它將檢測出用戶使用公用密碼的企圖並阻止他們。
強制執行MFA並設置了密碼保護後，NCSC和微軟現在建議我們不用再要求密碼複雜度了。我們可以移除密碼過期限制並將密碼長度縮短到8個字符。
4.以正確的方式進行身份驗證
- 啓用密碼哈希同步。
- 啓用Azure AD SSO，這比使AD FS的速度更快。如果AD掛掉，雲資源將仍然可以訪問。
- 啓用Azure AD設備註冊，這不會影響你管理設備的方式，但你會知道設備肯定是加入域的。在啓用Azure AD SSO之前，請勿執行此操作，否則你將陷入對AD FS的依賴。
- 確保擁有一些Windows Server 2016或更高版本的域控制器，並將域控制器證書更新爲啓用了替代舊域證書的域控制器身份驗證（Kerberos）模板。如果有系統加入了Windows 2003 SP2甚至XP SP3之前的域，則需要先刪除這些內容，然後再繼續操作。對於你的共享設備人員（例如前線工作人員），你會遇到受信任保護模塊（TPM）芯片容量限制，所以需要FIDO2密鑰。對於高級主管和AD域管理員或Azure AD全局管理員，請考慮將FIDO2密鑰與生物特徵選項結合使用。
- 安排好你的臨時帳戶流程。
5. 保護這些身份
如果你有預算，請申請AAD P2或M365 E5許可證。如果登錄看起來很奇怪，即使在通常不需要MFA的情況下它也會強制執行MFA。如果憑據被泄漏到了暗網，那麼它就會強制重置密碼。如果你預算不夠，至少要有compromised creds report，讓人每天看一遍報告。但這裏的前提是需要啓用Azure AD密碼哈希同步（PHS）。
6.處理好特權訪問基準
如果你的管理員習慣於隨時訪問所有內容，那麼現在正是他們改掉壞習慣的時候了。
Windows的所有版本都有一套稱爲用戶帳戶控制的基本策略。你需要在整個組織中一致地使用這些控制策略。至少你應該：
- 確保管理員、服務和應用程序帳戶專用於工作站、服務器或域控制器。
- 如果可能，請爲這三個類別提供特定類別的管理工作站。至少要有“管理工作站”的概念。
- 確保刪除了這些策略中的某些默認條目。
- 確保管理員一次都不具有對所有工作站或所有服務器的管理員訪問權限。不要讓你的組織機構對任何一個帳戶開放。將權限分成較小的組，按需開放。
- 限制對應用程序級別組的訪問。不能有“ALL DATACENTRE X”類型組或“ALL SQL SERVER”類型組。
- 限制服務/應用程序帳戶。拒絕它們交互式登錄。禁止它們進入本地管理員組。使用你的報告系統捕獲那些本地管理員組更改事件。
- 通過策略強制本地管理員組。如果你不這樣做，並且沒有設置規則，你將面臨巨大風險。
- 使用LAPS！你的環境中不需要過時的本地管理員密碼，LAPS可以爲你料理這些事情。而且，你能輕鬆控制誰可以訪問這些密碼。人們使用管理員賬戶登錄時應該有記錄，不應該是匿名的。
- 不要同步你最重要的帳戶。域管理員沒有業務登錄到Azure。控制你的“爆炸區域”。
- 高特權的組要儘量精簡。在Domain或Global Admin級別組中，你只需要少數幾個帳戶。對於那些Global Admin和具有類似功能的Azure AD組，我強烈建議Azure AD Privileged Identity Management限制對這些角色的訪問。是的，它需要AAD P2或M365 E5許可證，但只有添加這些功能強大的角色的帳戶才需要。
要做的工作總是很多的，但我建議你將上述策略作爲一個不錯的起點。是的，這些聽起來很困難，很昂貴，需要很長時間。是的，我們隨時都需要訪問這訪問那。
但失去一切的後果更爲嚴重，將付出更多代價，並且將花費更長時間，讓人們的工作和人際關係變得更糟。這些是基礎工作，就像鎖上前門，或在銀行卡上輸入PIN碼一樣。不管怎樣，更新這些規則，安排好你的流程。在幾十年的權限濫用之後，人們已經習慣了無限制地不斷訪問所有內容。在2017年6月，Maersk爲此付出了慘痛代價。很多組織依舊在重蹈覆轍，但改變其實是很簡單的，只要開始行動就夠了。擁有的權限越多，承擔的責任也就越重，遲早令人無法承受。
我敢打賭，你的組織並沒有什麼不同。濫用權限爲用戶帶來了不錯的體驗，但也對壞人敞開了大門。你的用戶和管理員需要了解他們的帳戶對組織構成了明顯的威脅，並且每個人都需要介入以幫助限制這些威脅。
其他措施
這篇文章專注於身份和訪問控制主題。但是安全環境的其他方面也是同樣重要的：
- 維護關鍵業務應用程序列表。當涉及到連續性計劃和安全措施時，請優先考慮表上的內容。這並不是說只對關鍵系統採取措施，對其他系統不聞不問。這裏說的是建立一致的基準。關鍵的東西一旦經過測試，就應該先獲得“更好的措施”。
- IT組織應該把淘汰過時的操作系統當作自己的優先任務，尤其是那些服務於核心業務的系統。這些系統不僅會有嚴重漏洞，而且很可能使你無法採用其他更現代的功能。
- 不要延遲補丁和更新。安全補丁、AV定義等——請勿等待，快速部署它們。設置最大增量。任何未打補丁的系統都應考慮採用自動隔離程序。讓應用程序負責人負起自己的責任。
- 使用數據。沒有數據，就不可能證明問題的嚴重性，沒法做計劃。一種糟糕的方法是使用中心化工具來收集數據。應該用去中心化的方法，單獨管理各個系統的報告。通過這種方式，你可以將整個環境對特定帳戶的影響最小化。
延伸閱讀：
原文鏈接：