身份認證沒有國界—企業聯盟整合

許多企業都為了如何管理不同部門、服務的帳號而傷透腦筋，各部門、單位有獨自的帳號權限，卻希望能夠整合起來，以便使用起來感覺更順暢、更方便，並且能有效的管理這些帳號。如果單純就企業內部環境中的應用程式或服務，應該很容易達到整合領域、單一身份認證、增加便利性、有效管理的目標，但是就算僅在企業內部環境這樣條件下，還是有其困難度。
在多個不同領域（domains）提供SSO（single sign-on）、帳號管理等，都是目前企業聯盟服務整合碰到的問題。利用XML與SOAP協定，企業得以將其下的用戶身份資訊與結盟夥伴（federated partners or departments）系統裡的身份權限做一個對應，使用者不需要記憶多個帳號，便可以在各領域通行。
目前已提出的有安全宣示標記語言（SAML, Security Assertion Markup Language）、自由聯盟架構（Liberty Identity-based Federation Framework）、網路服務聯盟（WS-Security）這些標準規格，來解決領域之間身份移轉認證的技術問題。但是一個夠好的整合機制還得看能否與協議外的領域做整合。當進行整合時，企業需要決定要將哪些使用者或客戶資訊提供給企業夥伴，身份資訊會被怎麼運用，提供這些用戶資訊將可能負擔哪些法律風險，以及需要簽署哪些法律協議以便因應任何狀況的發生。
企業建立跨領域服務整合最大的挑戰在於如何管理這些受信任的關係，並且如何確保企業和企業夥伴皆能有效實踐這些整合方案的安全需求。
建構企業聯盟
當本身擁有自己的身份帳號系統的企業，欲與他們的企業夥伴進行帳號或服務整合，這便是企業聯盟的概念（與企業內部各系統整合的SSO有所區別）。企業聯盟服務整合並不包含帳號建立、新增服務項目以及帳號管理，而實際上比較像是簡易版跨領域的單點登入（SSO）機制。
在一個企業聯盟服務整合機制中，企業允許另一個企業的使用者來對本身所授權的服務或應用程式進行存取。兩個企業的系統中都存有身份識別資訊，使用者只需使用一個帳號與密碼登入一次後，便能使用這個單一身份以適當的權限暢遊聯盟內各個企業。大部分的案例中，使用者感覺起來就像是單點登入。
一個企業聯盟服務整合的典型例子是「航空公司」和「租車公司」的結盟關係，若有一位客戶在某個活動獲得了紅利點數，而他的航空公司與某家租車公司剛好有企業聯盟的合作關係，此時企業聯盟機制便可讓這位客戶的個人資訊（像是紅利點數）移轉到租車公司的系統裡，讓他可以享受這家結盟夥伴所提供的車輛預約服務或特殊折扣。企業聯盟讓客戶能夠登錄一次資訊，便遨遊不同領域享受服務的權利，讓用戶感受到系統整合的便利。
聽起來很棒對吧？但是這樣的過程卻有許多風險。最糟的情況是，一個管理不良的結盟企業可能讓一個認證不當的用戶也能夠任意遨遊各個領域。如果企業對其他結盟企業來的用戶沒有做好管制，一個結盟企業的漏洞也就是 整個聯盟的漏洞所在，就算僅有一個結盟企業出問題，這個有問題的結盟企業也會讓整個聯盟都受其影響。
有三種做法可以讓結盟企業保護自己降低這些風險：限制外來聯盟用戶的使用權力、在適當的地方建立機制定期檢查結盟企業的安全性、訂定法律協議以便在結盟企業出事時能有其相關的責任與義務。
在實行企業結盟服務整合時，建立聯盟邊界和控制措施可以保護自己不致於被有問題的結盟企業所影響。經驗法則告訴我們，要適當的開放資源。舉例來說，一個機構和他的客戶做企業結盟，不要開放整個公司資源給客戶，而開放客戶存取客戶本身原有的資源。（參見「享受企業聯盟服務整合的好處」）

建立互信機制
實施企業聯盟服務整合，企業必須信任結盟企業以及其用戶，讓其能夠存取資訊和資源。但是，企業與結盟企業關係越是敏感的話，要建立適當互信也就越不容易。
這些結盟企業必須經常同步彼此安全政策和需求、認證機制、人員離退資訊、實施稽核、報表需求。
企業不會只想開放權限，卻不考慮先實施風險評估，所以，考量所有結盟企業的安全性與欲開放的資訊的重要性是必要的。
存取控管與認證機制都要非常小心。擁有昂貴資產的企業絕不可以僅使用簡單的使用者帳號和密碼來認證，至少也要用到複雜一點的認證機制，像是token認證。依據信任層度、認證難易度、來源等來提供給企業聯盟用戶的適當的資源。也就是說，若是只用單純密碼來做認證，僅提供受限制的資源給使用這些認證方式的用戶。
另外，結盟夥伴們彼此簽署的結盟協議中，需要規範注意人員離退資訊。各公司內部都會有離職或退休的人員。系統要確定能移除那些在該結盟企業中離職的人員，以避免這些離退的人員對聯盟的系統仍有不正當的存取行為。同樣地，這些結盟企業必須定時稽核是否有這些問題帳號。
企業聯盟的安全性與完整性，和用戶身份識別是密不可分。因此，結盟企業皆須認可一個取得與管理數位憑證的過程，而整個聯盟也都認可彼此都相信的憑證機構（certification authorities）金鑰的存放標準和廢止機制。
為了確認是否安全，許多企業會要求結盟夥伴參與或通過第三方的稽核機制或是安全標準（像是ISO17799或CoBIT），而不管結盟夥伴彼此靠這些安全標準或是自己所訂的安全需求來約束，在結盟協議中要規範，至少要讓企業接受其他結盟夥伴的安全規範定時稽核或檢驗，也包含必須互相告知所發生程序缺失或是資安事件。
企業聯盟所訂的法律協議，可用來確保所有結盟夥伴都能做好認證控管，確保各自架構的安全與完整性。並且規範企業聯盟，當沒有做到共同約定的安全要求時，要負擔哪些損失。
所有的結盟夥伴都必須建立一個稽核機制，來檢查其他企業夥伴是否有遵守法律約定所規定的相關安全需求。舉例來說，結盟企業本身要能夠證明確實地執行了認證機制、稽核紀錄是否正確、加解密的金鑰有完整的保護措施、整個系統架構都依照了標準來維護。
隨時檢查企業聯盟之間的活動行為可以確保服務品質（SLA），結盟企業彼此之間的結盟互信協議也可以一致。當結盟企業彼此準備好要建立透明的安全機制時，聯盟便可建立第三方的標準SLA稽核機制，或是使用聯盟企業彼此的互檢機制來達成。此外，結盟企業可分享稽核紀錄，像是登入紀錄、跨領域紀錄、權限改變紀錄，這些有影響彼此系統的紀錄。在聯盟中的任一個企業成員都應該利用這樣的資訊交換，彼此互助，以便讓企業聯盟運作的更為安全與正常。
最後，如果雙方發現有安全、存取限制、服務中斷、事件反應等問題時，結盟企業彼此須有一套協調機制。沒有一個系統是完美的，任何奇怪事情都有可能會發生。當發生可疑的問題，一定要小心求證，謹慎處理，並建立一套嚴謹的可疑事件通報機制、事件描述文件、事件反應方式、事件發生原因和解決方式，當發生事件時，這些處理機制都要能協助維持彼此的合作關係。
結盟前，企業應該先審慎評估哪些服務或資源該提供，以減少問題發生後的危害，並且得訂定相關法律保護條款以保護與合作夥伴的關係，最後，要維持聯盟長久的關係是需要好好努力的。
本文作者RICHARD MACKEY JR.是一家提供資訊安全服務SystemExperts公司的負責人，如果您對本文有任何建議，請來信到iseditor@asmag.com。