微軟特權訪問管理

2018-2022是私有云混合雲在中國最火熱的時代,私有云將在中國從摸索走向成熟階段,隨着雲技術的火熱,下一個企業必須要思考的將是信息安全的問題,現在企業都在導入雲計算技術,建置更多的信息應用系統以從中獲取信息化帶來的價值。那麼隨着帶來的一個隱患就是,管理員要管理的基礎架構和應用系統數量越來越多,這時候管理員賬戶就變的很重要了,如何保證管理員賬戶能夠安全,如果保證管理員賬戶的管理操作可控,可記錄,如果保證雲資源管理員和租戶虛機的隱私問題,將是企業信息化接下來必須要考慮的安全點


老王之前做企業諮詢實施的時候發現國內企業信息化,發現有一些現象,企業IT部門的管理員,可以很輕而易舉的獲得多個高權限的管理賬號,有些企業信息項目外包出去,外包人員需要的管理員賬戶,做完項目也不回收。導致了Domain Admins組有大量的用戶,這其實是極大的一個安全隱患,越多的高權限賬戶就有越多的風險,Hacker或者內部惡意管理員只要隨便破解找到一個管理員的賬號密碼,就可以利用這個賬號訪問所有的域內系統,如果沒有虛擬機保護機制,還可以利用此賬戶去窺探任意租戶虛擬機的內容。


針對於這些雲技術時代產生的安全隱患,微軟在Windows Server 2016開始,正式引入 Privileged Access Management  特權訪問管理的概念,PAM在老王看來,它不是指的某一個特定的技術,而是一套控制管理員特權執行生命週期的方法論,通過PAM就可以控制管理員賬戶的獲取-保護-執行-監控,完整的管理生命週期。


下圖是PAM的方法論流程圖


mim_pim_setupprocess.png



1.準備:這一個步驟要梳理出來,當前生產林中那些組屬於特權保護組,將要在堡壘林中創建不存在用戶的安全主體(堡壘林概念下面會提到),現有生產林中特權組裏面,有哪些用戶是應該要剔除來的,可根據安全需要酌情處理,最好能夠只保留系統必須使用的賬號,將個人管理員從中剔除。

2.保護:控制保護管理員賬戶獲取,可以針對於特權賬戶設置MFA,當用戶請求管理員權限時通過MFA多因子驗證纔可以獲得,WS2016開始支持直接調用Azure MFA,MIM支持智能卡MFA。

3.操作:通過身份驗證後,用戶的特權權限申請請求將通過人爲審覈,或門戶工作流審覈,審覈通過後,用戶將獲得時效性或永久性權限,如果是時效性權限,當時間到達時,用戶令牌將失去特權權限,不能再執行任何特權操作。

4.審計:PAM需要特權訪問請求的審計,警報和報告,每一次特權申請和審批結果都應該被詳細記錄,您可以查看特權訪問的歷史記錄,並查看執行活動的人員。您可以決定活動是否有效,並輕鬆識別未經授權的活動,例如嘗試將用戶直接添加到生產林中的特權組。此步驟不僅對於識別惡意軟件而且對於跟蹤“內部" 惡意管理員也很重要。


可以看到PAM提出了一套很好的對於特權賬戶的生命週期管理理論,這些理論要想要落地實現,還是離不開技術工具的支持,在2008R2,2012R2時代,一些企業也認識到了這一點,要控制管理員賬戶的安全,要可控,要監控,但是那時候並沒有2016這麼多的工具,因此主要還是要通過管理規範推動,通常在2016之前,我們去給企業做這種安全建議的時候會這樣說


1.針對於個人管理員賬戶,設置密碼策略,定期更改複雜性密碼

2.針對於應用系統,儘量不要每個賬戶都用最高權限,去technet查詢最小需要安全權限

3.建立管理員組成員登記表

4.開啓安全策略審計,審計管理員賬號登陸,訪問

5.管理員操作時儘量通過工作站執行,在工作站上安裝殺毒軟件,使用防竊取技術

6.利用第三方廠商軟件實現權限申請審批

7.利用第三方廠商軟件實現密碼破解檢測


其中一些方法到2016時代也並不過時,但是一些安全點到了2016時代,微軟自身就已經有了更好的技術去實現。


2016我們有了JIT,Shadow Principal,JEA,MIM這些來控制管理員賬戶安全的新技術,下面我們就來解釋一下每項技術發揮的作用


Just-in-time 是微軟提出的一種即時管理的概念,希望針對於一部分管理員實現,只在需要的時候請求權限,當所需要的時間到達後,即回收管理權限,不要給所有請求都分配永久管理員,這個特別適用於國內外包公司的場景,外包人員需要做項目,可以臨時申請管理員權限,項目結束時間到達後自動回收賬號權限,或者一個場景,IT管理員需要臨時登錄到租戶虛擬機或應用系統虛擬機,經過審批後,獲得一個時效性權限,時間到達時自動回收。


微軟不僅提出概念,也有實際落地的技術工具,微軟在AD2016中引入了PAM新功能,不借助任何工具,只通過AD域本身就可以實現,對用戶設置有時效性的成員資格,當時間到達時用戶將自動失去成員資格


由域控制器來管理並在達到TTL限制時將其刪除。這也適用於複製,因爲複製了TTL值結束時間,並且將在所有域控制器上本地刪除鏈接。與此同時,還有一些Kerberos增強功能可以真正利用基於時間的組。當KDC創建票證時,它會將Kerberos票證生命週期限制爲可能的最低生存時間(TTL)值。如果用戶還剩15分鐘,直到組成員身份的TTL到期,KDC將只創建另外15分鐘的TGT/TGST,當票證已過期且請求新票證時,過期的組成員資格的SID將不在,使用此功能,您可以臨時爲用戶提供基於較小時間限制的系統管理員訪問權限。DC將維護和刪除成員資格,它不會受到複製融合或Kerberos票證生命週期(默認爲10小時,可在7天內續訂)的不利影響。


實際使用時,首先需要必須要升級域控爲2016,並確保林功能級別域功能級別爲2016,升級後,需要手動在域控上面啓用PAM新功能,才能實現時效性的組成員資格

命令如下

Enable-ADOptionalFeature “Privileged Access Management Feature” –Scope ForestOrConfigurationSet -Target admin.com

2018-12-31_111536.png

創建時效性成員資格

$TTL = New-TimeSpan -Minutes 10

Add-ADGroupMember -Identity“Domain Admins”-Members “Tony”-MemberTimeToLive $TTL

2018-12-31_111740.png

由於Tony臨時獲得了Domain Admins權限,可以登錄到域控,但是查看Klist可以看到令牌權限時有時效的

2018-12-31_114005.png

查看管理員組時效成員資格,可以看到Tony的TTL時效資格在不斷變化

Get-ADGroup -Identity “Domain Admins” -Properties * -ShowMemberTimeToLive |fl member

2018-12-31_112317.png

當時效到達時,Tony將自動離開管理員組

2018-12-31_112940.png

時效到達後使用whomi /groups雖仍可以看到屬於管理員組,但是此時已經不能執行網絡上管理操作,註銷再登錄時權限也將徹底失效

2018-12-31_114203.png

這是JIT一個最簡單的示例,簡單但是實用,他對現有環境的變動最少,只需要升級AD2016即可實現,時效性資格功能也是後面PAM更復雜場景的基石。


如果企業不準備構建複雜的生產林,堡壘林場景,那麼就可以利用此功能達到控制特權管理執行的目的


當有可被識別爲臨時性的訪問需求時,請申請人口頭告知組長,再由組長執行命令授予臨時時效性成員資格,或者如果希望此過程更加標準化,可以藉助於Sharepoint+SCO或者SCSM+SCO實現Web申請,我給個思路,在Sharepoint創建一個權限申請列表,再創建一個審覈記錄列表,權限申請列表包括申請賬號,目標特權組(列表或預先填充),申請時效,申請原因,申請拿到後,會由部門經理或組長進行審批,SCO會監控這樣一條新紀錄的產生,當看到工作流狀態爲已批准的時候,將填寫的記錄轉換爲變量,通過databus傳遞給下一個活動,通過腳本操作連接到AD域,將拿到的用戶變量,目標組變量,申請時效變量進行填充,執行成功後可郵件通知或Sharepoint站內信通知申請人,同時databus將數據傳遞到下一個活動,把申請人,申請時效,申請特權組,申請原因,審批人,這些數據,填充到另外一個特權審計表單,記錄成功後流程結束,這裏只是給出大家一個思路,作爲ITpro我們可以通過Sharepoint+SCO實現或者利用SCSM+SCO實現,如果有開發人員配合更加方便,直接請開發人員在Web門戶上面做好表單,將輸入的數據做成變量,調用powershell執行即可。


那麼,這是一個最基本的場景,在微軟的PAM規劃中,理想情況應該是構建一個堡壘林,如下圖所示,微軟提倡的是將特權管理賬號徹底的單獨拿出來,放到一個堡壘林中,生產林中只保留用戶賬戶,應用程序所必須要的賬戶,兩個林之間僅創建單向傳入林信任,這樣做的好處是最大程度上減少由破解管理員造成對生產林的危害,因爲管理賬號根本就不存在生產的林中,惡意程序也無法掃描到生產林中的管理員哈希。


當堡壘林中的管理員要管理生產林的時候,需要通過人爲或門戶的申請,申請通過後會被時效性或永久性的加入到堡壘林中的陰影主體,我們提前會把生產林中的特權賬號,特權組,在堡壘林中創建成一個陰影主體,當管理員需要特權的時候,會申請特權組或特權用戶的權限,當審批通過的時候,幕後會按照時效性把生產林中的用戶加入到陰影主體中去,這個用戶就可以連接到生產林中執行管理操作,此時在管理林用戶用戶的whoami /groups命令裏面可以看到生產林特權的SID,當時效到期後自動拿到生產林的權限。


mim_pim_howitworks (1).png

上面說了很多名詞,這裏再簡單的科普一下


在Windows系統中,當用戶登錄時,會發生以下幾個步驟


1.用戶輸入賬戶 密碼 域

2.Local Security Subsystem向域控申請用戶的Session Ticket

3.Local Security Subsystem向域控申請Workstation的Session Ticket

4.DC上的Kerberos Service確認用戶密碼和計算機密碼正確後,回傳ticket給用戶端

5.用戶端Local Security Subsystem收到回傳的ticket產生Access Token

6.使用Access Token去執行接下來的進程


Access Token裏面會包括用戶的SID,如果是域用戶SID由域SID+RID主機分發的編號構成,用戶所屬組的SID,用戶所擁有的特權。

如果企業有采用DAC動態訪問控制,Token中也會包括聲明。


每一個AD裏面的用戶屬性裏面除了自己的SID,還會有一個sidhistory的屬性,該屬性於windows 2000時代引入,目的是爲了確保當發生域用戶跨域遷移時,讓遷移後的用戶仍然能夠訪問遷移前能夠訪問的資源,因爲當用戶遷移到一個新的域,就會由所在域的RID主機產生一個新的編號,就會得到一個新的SID,這樣如果訪問以前的資源時,對比文件系統ACL的列表發現沒有用戶新域SID,則訪問被拒絕,通過sidhistory可以把用戶遷移前的SID,填充到遷移到新域後用戶的sidhistory屬性裏面,這樣訪問之前可以訪問的資源時,發現用戶具備匹配的sidhistory,則訪問被允許。


後來微軟發現sidhistory屬性存在安全隱患,一旦兩個域創建信任後,在某些情況下,受信任域中的管理員和超級用戶可以從信任域獲取特權帳戶的SID。這些SID不保密,大多數情況下,您可以通過查看信任域中資源的訪問控制列表(ACL)來獲取此信息。獲得SID後,它將附加到受信任域中的任何用戶對象,特別是其SIDHistory屬性。當此修改後的帳戶跨越現有信任關係時,從受信任域到信任域,它將有效地擁有受感染帳戶的所有權限,可能會一直提升到域管理員或企業管理員級別


在Windows Server 2000 SP4微軟引入了SID篩選的功能,防止SID欺騙提權,SID篩選使安全信任管理員能夠丟棄使用可能是欺騙候選者的SID的憑據。在域中創建安全主體時,域SID包含在安全主體的SID中,以標識創建它的域。域SID是安全主體的重要特徵,因爲Windows安全子系統使用它來驗證安全主體的真實性。

同樣,從信任域創建的傳出外部信任使用SID篩選來驗證從受信任域中的安全主體發出的傳入身份驗證請求是否僅包含受信任域中安全主體的SID。這是通過將傳入安全主體的SID與受信任域的域SID進行比較來完成的。如果任何安全主體SID包括來自受信任域的域SID以外的域SID,則信任將刪除有問題的SID。

如果用戶嘗試從受信任域升級,則用戶將從信任域添加SID到該用戶的SID歷史記錄。信任鏈接將此視爲潛在的危害,並從身份驗證請求過濾所有不是來自受信任域的SID。如果受信任域中的用戶是從另一個(第三個)域遷移的,則不允許通過信任鏈接從第三個域中獲取SID信息。


鋪墊都做好了,那麼就可以來看主菜了,在微軟規劃的PAM模型中,理想情況下分爲堡壘林和生產林,管理賬戶都在堡壘林,當執行管理操作的時候,堡壘林的管理員將臨時獲得生產林中特權用戶或特權組的SID,這項技術得以實現,主要歸功於Windows Server 2016AD域的Shadow Principals,不論是通過Powershell獲得權限,還是通過MIM門戶獲得權限,底層都使用的Shadow Principals,通過Shadow Principals允許堡壘林管理賬戶跨林得到生產林SID


Shadow Principals涉及到的屬性


msDS-ShadowPrincipalContainer

msDS-ShadowPrincipalContainer是msDS-ShadowPrincipal對象的專用容器,在Configuration NC的Services容器中創建一個默認容器。

CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com

可以在其他位置創建主體容器,但不能使用Kerberos。


msDS-ShadowPrincipal

此類表示外部林的主體。只能在Shadow Principal容器中創建,它必須具有msDS-ShadowPrincipalSid值。

Shadow主體可以代表任何安全主體用戶,安全組或計算機。它還有成員屬性,這裏是PAM和Shadow Principals的很酷的地方,我們可以像時效組成員一樣在成員資格上設置TTL值。如果Shadow Principal駐留在默認的CN = Shadow Principal Configuration,CN = Services,CN = Configuration,DC = X容器中,任何域用戶擁有任何Shadow Principal的成員資格將與任何其他組成員一樣添加到Kerberos票證中。一個限制是它只能在其自己的林中擁有主體成員。

如果設置了成員資格的TTL值,它將與Kerberos集成,並且票證的生命週期將設置爲最短的到期TTL值。


msDS-ShadowPrincipalSid

此屬性包含外部林中主體的SID,屬性編入索引。它具有約束,因此您無法從其自己的域或其自己的林中的任何其他域添加SID。並且必須將林信任配置爲能夠從其他域添加SID,確保針對兩個林之間開啓sid history,關閉sid filtering。


具體實現,我們會在堡壘林中,在msDS-ShadowPrincipalContainer容器裏面,創建生產林中如Domain Admins,Enterprise Admins等組或用戶的msDS-ShadowPrincipal克隆對象,當管理員需要對生產林執行特權操作的時候,會有專人手動將堡壘林裏面沒有權限的用戶加到堡壘林msDS-ShadowPrincipal對象的member成員裏面,這樣這個用戶就可以獲得時效性或永久性的,生產林中的SID,如果有MIM,當審批通過後會自動添加,如果有Sharepoint和SCO,也可以做成流程審批通過自動添加。


下面我們通過實驗驗證

當前環境具備一臺2012R2的生產域控,一臺2016的堡壘林域控,生產林abc.com,堡壘林admin.com,一臺堡壘林工作站,當前生產域控Domain Admins組成員已清空,堡壘林中需要臨時登錄到生產林域控進行巡檢。


在此示例中,我們將創建單向林可傳遞信任。我們需要禁用SID 篩選和Enable sidhistory,以便當admin域中的用戶登錄到abc中的服務器時,不會過濾掉SID,在Windows Server 2016中,此方案有一種新的信任類型,稱爲PIM信任。在早期版本中,不可能將像Domain Admins和Enterprise Admins這樣的SID與SIDHistory一起使用,它們總是被過濾掉。因此我們還必須啓用PIM Trust選項,除此之外還需要在兩邊域控DNS配置到對方域名的DNS條件轉發器。


需要注意,如果生產林域控是2012R2版本,請按照順序安裝以下補丁,2012R2域控纔可以擁有PIM Trust命令

Windows8.1-KB2919355-x64 

Windows8.1-KB2919442-x64 

Windows8.1-KB3021910-x64 

Windows8.1-KB3172614-x64


生產林域控執行

netdom trust abc.com /Domain:admin.com /Add /UserD:[email protected] /PasswordD:* /UserO:[email protected] /PasswordO:*

netdom trust abc.com /domain:admin.com /ForestTRANsitive:Yes

netdom trust abc.com /domain:admin.com /EnableSIDHistory:Yes

netdom trust abc.com /domain:admin.com /EnablePIMTrust:Yes

netdom trust abc.com /domain:admin.com /Quarantine:No

如果是中文版系統,需要輸入chcp 437進入英文code page,否則會出現命令無法執行成功

2018-12-31_163015.png

堡壘林域控必須爲Windows Server 2016及以上,林功能與域功能級別至少2016,只有2016的林域功能級別才能實現後面時效性的組成員資格,才能具有陰影主體屬性。確認全部升級到2016後務必手動開啓PAM功能

Enable-ADOptionalFeature “Privileged Access Management Feature” –Scope ForestOrConfigurationSet -Target admin.com

2018-12-31_111536.png

堡壘林域控執行

netdom trust admin.com /domain:abc.com /ForestTRANsitive:Yes 

2018-12-31_163854.png

並且不要忘記爲Admin域中的信任啓用Kerberos AES加密,在System容器中的ABC對象上打開屬性並標記複選框:其它域支持Kerberos AES加密

2018-12-31_164522.png

在堡壘林爲生產林特權組Domain Admins創建陰影主體


$CORPPrincipal = "Domain Admins"

$CorpDC = "12dc.abc.com"

$ShadowSuffix = "abc-"

$CorpShadowPrincipal = Get-ADGroup -Identity $CORPPrincipal -Properties ObjectSID -Server $CorpDC

$ShadowPrincipalContainer = "CN=Shadow Principal Configuration,CN=Services,"+(Get-ADRootDSE).configurationNamingContext

New-ADObject -Type "msDS-ShadowPrincipal" -Name "$ShadowSuffix$($CorpShadowPrincipal.SamAccountName)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $CorpShadowPrincipal.ObjectSID}

2018-12-31_165020.png

創建完成後可以在堡壘林域控連接ADSI配置分區可以在下面路徑找到創建的陰影主體

CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com

2018-12-31_165411.png

如果你點開創建好的陰影主體對象,你會看到它的msDS-ShadowPrincipalSid和陰影主體在生產林裏面的SID一模一樣,這是創建Domain Admins組陰影主體的做法,用戶陰影主體同樣。


下面模擬發生權限請求,人爲批准特權訪問生產林操作,將堡壘林管理員用戶Mike,臨時加入到Domain Admins陰影主體,添加前Mike無任何權限,僅爲普通用戶。

Set-ADObject -Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com" -Add @{'member'="<TTL=600,CN=Mike,OU=ITAccount,DC=admin,DC=com>"}

2018-12-31_170202.png

執行完成後可以在堡壘林Domain Admins陰影主體對象member屬性處看見mike已經作爲成員

2018-12-31_170346.png

現在Mike用戶已經可以登陸到生產林域控,到這一步其實已經可以判斷生效

2018-12-31_171134.png

查看Kerberos部分,我們可以使用klist列出Mike用戶的當前票證

2018-12-31_171042.png

除了時效性,事實上我們也可以爲mike分配一個永久性的生產林權限,可以直接GUI添加永久陰影主體成員,也可以使用之前PS添加的命令,將TTL設置爲0即可,設置之後用戶Kerberos票證生命週期將恢復默認十小時

2018-12-31_204209.png

如果管理員希望撤銷永久性陰影主體權限或取消還在時效中的成員權限,運行命令

Set-ADObject -Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com" -Remove @{'member'="<TTL=0,CN=Mike,OU=ITAccount,DC=admin,DC=com>"}

2018-12-31_204758.png

GUI查看發現陰影主體member成員已經爲空

2018-12-31_204914.png

mike註銷後將失去生產林的一切管理權限

2018-12-31_205012.png

進一步理解,事實上陰影主體使用的並非是SIDHistory技術,當mike被添加到陰影主體後,SIDhistory並不會添加,因此說明,被添加到陰影主體的成員登陸令牌裏面,除了用戶SID,所屬組SID,User Right,一些默認SID,還會包含所屬陰影主體的SID。


當我們通過陰影主體成員訪問生產林幕後發生的事情如下


  • 用戶嘗試RDP到生產中的資源 - >資源不知道該用戶 - >需要身份驗證和授權

  • 身份驗證請求將重定向到admin林中的KDC(密鑰分發中心 - > DC)

  • KDC構建如上所述的SID列表,包括來自生產的Domain Admins的鏡像SID

  • 生產中的DC檢查組在其數據庫中嵌套由管理林發佈的令牌呈現的SID

  • 生產DC根據令牌添加組嵌套


通過這個實驗,相信大家對於微軟提出的PAM操作模型有了更深入的理解,我更希望的是更多人能夠理解,與我討論,思考在企業裏面的應用點,並在企業裏面試着應用,可以看到,這是一種重新定義特權訪問的理念,將管理權限梳理成時效性權限,將管理員梳理到單獨的堡壘林利用陰影主體提供穿透訪問。實際應用時候不要着急一刀切,把管理權限全部移動到堡壘林,可以根據企業安全需求,識別出來那些是可以移動的,逐步將管理權限移動。


不論是單域控不構建堡壘林的場景,或是堡壘林的場景,我們都能實現時效性訪問,本文演示的是最原始的powershell操作方式,對應到現實裏面最後添加成員到陰影主體的操作應該由組長或者部門經理執行,那麼我們可以看到,實際上添加也好,刪除也好,陰影主體,申請人,TTL時效,都可以封裝成變量,就向上面提到的思路,管理員可以藉助Sharepoint+SCO或SCSM+SCO,或請開發人員幫忙,通過Web實現流程化的權限申請,權限回收,權限申請審計。


擴展瞭解,與PAM接近,Azure上面也有一個PIM服務,可以執行以下操作,它與PAM概念不同的是,PAM是一套用於梳理數據中心基礎架構特權管理模型的方法論和落地工具,PIM是微軟對租戶提供的用於租戶在Azure平臺上面使用時的特權身份管理功能。


  • 查看爲哪些用戶分配了特權角色來管理Azure資源,以及在Azure AD中爲哪些用戶分配了管理角色

  • 啓用按需,“及時”管理訪問Microsoft Online Services(如Office 365和Intune),以及Azure資源訂閱,資源組和單個資源(如虛擬機),具備多個定義好的角色

  • 自動和Azure MFA集成,租戶申請激活PIM角色,經過MFA驗證纔可以申請成功

  • 由Azure後臺實現面對租戶申請PIM角色使用的JEA,JIT特性

  • 查看管理員激活的歷史記錄,包括管理員對Azure資源所做的更改

  • 獲取有關管理員分配更改的警報

  • 需要批准才能激活Azure AD特權管理員角色

  • 檢查管理角色的成員身份,並要求用戶提供繼續成員資格的理由

  • Azure PIM功能體驗比本地PAM更好,本地PAM面對是數據中心,AzurePIM實現了面向多租戶,爲每個租戶提供JEA、JIT、PAM體驗。


那麼MIM主要是起什麼作用的呢,MIM 2016 本身這個產品是FIM的延續,具備跨應用的身份同步,密碼自助重置,證書管理,密碼更改通知,PAM實現,和AzureAD整合混合同步及混合報告

在PAM的體系裏面,MIM可以做到保護——操作——升級的三個過程,與單獨的Powershell不同,通過MIM可以配置用戶使用多因子登陸,MIM會基於Sharepoint建立一套門戶,用於權限申請審批,自帶工作流。

QQ截圖20181230174922.png


QQ截圖20181230175059.png



QQ截圖20181230174943.png

除此之外MIM門戶還原生具備報告審計的功能,可以看到每次申請的歷史記錄,以及審批人


MIM實現PAM比原生的Powershell更加標準化,但底層都使用同樣的功能實現,它會把每一個安全主體創建成一個個角色,供用戶申請審批

MIM架構支持高可用部署

MIM不能部署在域控上面,可以部署多臺MIM服務器容錯MIM服務,堡壘林域控部署多臺,後臺SQL數據庫支持AG/FC/鏡像高可用,Sharepoint支持場架構

由於MIM部署門戶非常的複雜,因此如果只是爲了要PAM的門戶申請和升級功能也未必一定要部署MIM,可以採取老王上面提到的Sharepoint+SCO思路嘗試

QQ截圖20181231224114.png

MIM PAM部署參考鏈接

https://docs.microsoft.com/zh-cn/microsoft-identity-manager/pam/configuring-mim-environment-for-pam

https://blogs.msdn.microsoft.com/connector_space/2015/08/25/installation-of-the-privileged-access-management-pam-feature/

https://blogs.technet.microsoft.com/meamcs/2018/12/26/step-by-step-mim-pam-setup-and-evaluation-guide-part-1/


這樣我們就把JIT,陰影主體,MIM的概念和邏輯關係都理理清楚,那麼JEA是做什麼的呢,它是Powershell5.0的一個新功能,幫助實現最小化特權管理


通過利用代表常規用戶執行特權操作的虛擬帳戶或組託管服務帳戶,減少計算機上的管理員數量。我們會開啓一個虛擬賬戶的功能,當用戶要執行特權操作的時候會喚醒虛擬賬戶去實際執行,類似的技術,在微軟早期其它產品中也可以看到

QQ圖片20181231214008.jpg

通過創建配置文件,控制運行用戶可以運行的cmdlet,函數和外部命令操作

通過轉錄和日誌更好地瞭解用戶正在做什麼,這些轉錄和日誌可以準確顯示用戶在會話期間執行的命令


刪除管理權限並不總是很容易。考慮DNS角色與Active Directory域控制器安裝在同一臺計算機上的常見方案。您的DNS管理員需要本地管理員權限才能解決DNS服務器的問題,但爲了做到這一點,您必須使他們成爲具有高權限的“Domain Admins”安全組的成員。此方法有效地使DNS管理員可以控制整個域並訪問該計算機上的所有資源。


JEA通過幫助您採用最小權限原則幫助解決此問題。使用JEA,您可以爲DNS管理員配置管理端點,使他們能夠訪問完成工作所需的所有PowerShell命令,但僅此而已。這意味着您可以提供適當的訪問權限來修復中毒的DNS緩存或重新啓動DNS服務器,而不會無意中授予他們Active Directory的權限,或瀏覽文件系統或運行潛在危險的腳本。更好的是,當JEA會話配置爲使用臨時特權虛擬帳戶時,DNS管理員可以使用非管理員連接到服務器憑據並且仍然能夠運行通常需要管理員權限的命令。此功能使您可以從具有廣泛特權的本地/域管理員角色中刪除用戶,謹慎控制他們在每臺計算機上可以執行的操作


JEA配置參考:https://docs.microsoft.com/en-us/powershell/jea/prerequisites


JEA尤其適用於一些託管執行賬號,如VMM託管賬戶,SCOM監控賬戶等,一些託管賬戶,任務執行賬戶,不再必須要使用Domain Admins賬戶,只需要分配一個user,然後藏入虛擬account即可。


如果將JEA,JIT,陰影主體這幾個技術串起來我們可以完整實現PAM的操作效果,用戶在堡壘林申請權限,審批通過後會JIT時效性加入陰影主體成員,加入到的陰影主體也是JEA定義的保護組,申請記錄及審批記錄會通過MIM或Sharepoint審計,這個用戶登錄後會連接到一臺工作站執行管理操作,有了JEA可能特權組都不一定非要給Domain Admins,普通的管理員組就可以完成,因爲幕後會有藏好的虛擬賬戶執行管理操作,當用戶在工作站執行生產林管理操作的時候,能執行的命令操作受JEA配置文件的限制,且管理操作完全通過虛擬賬戶執行,當JIT時效到期後,用戶將完全失去到生產林及工作站的管理權限。


現在我們把2016的整個安全模型串起來

  1. 梳理生產林管理員,控制管理員數量,在堡壘林建立安全主體,針對於需要獲取權限的堡壘林用戶開啓多因子驗證

  2. 針對生產林主要服務器,堡壘林工作站,生產林工作站,開啓Credential guard,Remote guard,防止哈希破解,配置Windows Defender安全防護

  3. 通過MIM或Sharepoint等其它門戶,對用戶的特權操作進行審計,通過JEA日誌記錄審計執行命令。

  4. 通過MBAM管理加密重要服務器磁盤加密

  5. 通過SCOM或公有云OMS對服務器進行安全狀態診斷,通過APM或Application Insights對應用程序進行可用性/性能/安全診斷。

  6. 通過ATA進行入親檢測分析,預測對於生產林存留管理賬戶的破解,異常登錄行爲,整體分析AD域及syslog

  7. 通過Shielded VM對主機和虛擬機進行安全綁定,確保虛擬機只能在允許的主機啓動,每次虛擬機啓動需要經過驗證,虛擬機無法被拷貝到其它主機啓動。

通過PAM涉及到的JIT,JEA,陰影主體來管理控制特權執行的生命週期,通過Shielded VM控制惡意拷貝虛擬磁盤,通過ATA對域內賬號破解進行入親檢測,這三個2016最外圈的安全體系,互幫互助,構建更好的安全體系。關於Shielded VM和ATA我的好朋友ZJUNSEN已經寫了很好的實作博客,大家感興趣可以去看。

QQ截圖20181231220322.png


QQ截圖20181230175124.png

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章