AAE提供Credentials作為敏感信息的管理模塊。
官方說明如下：
這些憑證由 Credential Vault 服務(wù)加密县习，以符合 NIST SC-28 并防止未經(jīng)授權(quán)的訪問或憑證泄露。只有加密的憑證從 CR 傳輸?shù)綌?shù)據(jù)庫服務(wù)器烁设，并以加密形式存儲(chǔ)在數(shù)據(jù)庫中鄙早。數(shù)據(jù)加密密鑰使用 FIPS 140-2 1 級(jí)驗(yàn)證模塊生成的 AES 256 位密鑰對(duì)所有憑證進(jìn)行加密，以滿足 NIST IA-7枫甲、SC-12 和 13 關(guān)于對(duì)加密模塊實(shí)施身份驗(yàn)證機(jī)制的要求源武，從而符合適用聯(lián)邦法律的要求。
在v10想幻，Credential相對(duì)簡(jiǎn)單粱栖。只需要?jiǎng)?chuàng)建后直接在AAE客戶端套用就可以了。
從v11.x開始混合了RBAC的概念脏毯，不同的角色管理不同的密碼信息闹究。
保險(xiǎn)箱的管理和credential的管理區(qū)分開來后應(yīng)對(duì)更加復(fù)雜的企業(yè)級(jí)敏感信息管理。
另外還有Locker Management（保險(xiǎn)箱管理）食店。沒有放進(jìn)保險(xiǎn)箱的憑證不允許在客戶端使用跋核。
由此，保險(xiǎn)箱的創(chuàng)建是憑證管理的第一步叛买。首先要確保Locker權(quán)限已經(jīng)賦予某一個(gè)用戶砂代。
默認(rèn)admin沒有l(wèi)ocker Admin權(quán)限，也不允許編輯
然后率挣，創(chuàng)建locker:
創(chuàng)建過程中會(huì)有Locker管理權(quán)限的分配問題：
有關(guān)各種角色擁有的權(quán)限如下圖：
這里要注意的是刻伊，consumer才是消費(fèi)Credentials的主體。
機(jī)器人或者腳本想要使用憑證就需要保證有這個(gè)權(quán)限椒功。AAE的設(shè)計(jì)不允許用戶直接成為消費(fèi)者捶箱，一定要以某個(gè)角色成為消費(fèi)者(consumer)。
創(chuàng)建角色時(shí)要考慮的點(diǎn)如下：
- 區(qū)分憑證消費(fèi)者和憑證維護(hù)者动漾。
- 是否使用第三方平臺(tái)通過API完成密碼自動(dòng)更新丁屎，可參照。
image.png
創(chuàng)建的consumer角色被locker分配后旱眯，我們可以開始創(chuàng)建憑證晨川。
image.png
創(chuàng)建憑證界面如下：
image.png
這里要考慮的點(diǎn)是：
1.密碼維護(hù)方式：統(tǒng)一憑證信息 vs 不同的bot調(diào)用憑證時(shí)獲取的值是不同的（細(xì)節(jié)待驗(yàn)證）。
2.安全：掩碼是需要的删豺，尤其是密碼共虑。This is password(部分AAE11.X)就有些尷尬。因?yàn)闃I(yè)務(wù)系統(tǒng)設(shè)計(jì)時(shí)不一定嚴(yán)格按照type為password來設(shè)計(jì)呀页。如果選中這一項(xiàng)就可能導(dǎo)致憑證信息無法在業(yè)務(wù)系統(tǒng)里使用妈拌。
如果不設(shè)置，密碼信息就可以通過insert Keystroke方式打印出來蓬蝶。多一個(gè)安全隱患尘分。
其他信息可以移步這里猜惋，不多寫了。
