任何安全控制，都建立在一個前提之上：企業必須先知道有哪些資源、誰負責管理，以及誰可以存取這些資源。
前一章提到，企業管理規範並不是直接套用國際框架，而是先整理出共同的管理面向，再將不同框架中的控制要求，轉化成企業可以長期執行的管理要求。
而在這些管理要求中，最需要優先建立的，通常不是防火牆、加密或監控，而是企業對資源與身分的基本掌握。因為如果企業不知道環境中有哪些資源、不清楚誰負責管理，也無法掌握哪些人擁有哪些權限，後續建立的安全控制就很難真正落實。
因此，企業管理規範通常需要先處理幾個基礎問題：資源是否能夠被清楚識別與管理、身分是否具有明確的歸屬，以及人員與系統是否只取得完成工作所需要的存取權限。
資產管理之所以會成為重要的管理基礎，是因為企業後續進行安全管理時，必須先知道「管理的對象是什麼」。
因此，每一項資源都應具備完整且一致的管理資訊，例如用途、所屬單位、負責人、成本中心以及資料等級等。在雲端環境中，也通常會透過命名規範（Naming Convention）以及標籤（Tag）機制，建立一致的識別方式。
這些資訊看似只是管理上的細節，但當環境規模逐漸增加之後，它們會直接影響資產盤點、成本分析、權限管理以及事件調查。例如發生安全事件時，如果無法快速確認某項資源屬於哪個單位、由誰負責，事件處理就很難有效展開。
因此，資產管理的目的不只是「知道有哪些資源」，而是讓每一項資源都具備清楚的管理脈絡，使後續的安全控制能夠找到明確的管理對象與責任歸屬。
當企業開始掌握環境中的資源之後，下一個需要處理的問題，就是這些資源究竟由誰管理、由誰操作，以及哪些操作是由系統或應用程式所執行。
在現代資訊環境中，大部分的操作都會透過身分（Identity）完成。無論是建立資源、修改設定、部署服務，甚至執行自動化流程，都可能涉及使用者、服務帳號或應用程式身分。
因此，企業通常會要求重要資源建立在企業身分與明確的責任歸屬之下，而不是依賴個人帳號進行管理。這樣除了有助於資產交接與人員異動，也能讓後續的操作紀錄與權限檢視具備清楚的追溯關係。
換句話說，資產管理與身分治理並不是兩個完全獨立的管理議題，而是需要彼此連結。企業不只需要知道「有什麼」，也需要知道「誰在管理、誰在使用」。
當資源與身分之間建立清楚的關聯之後，接下來需要處理的就是存取範圍。企業不可能讓所有人都可以存取所有資源，因此需要根據角色、工作內容以及實際業務需求，決定適當的權限範圍。
這也是 最小權限（Least Privilege） 與 業務知悉需求（Need-to-Know） 兩項原則的核心。最小權限強調使用者、服務帳號以及系統元件，只取得完成工作所需要的最低權限；業務知悉需求則強調，只有因工作需要的人員，才能存取相對應的資料與資訊。
對於高權限帳號，則應進一步要求多因素驗證（Multi-Factor Authentication, MFA）等強化措施，降低管理權限遭到盜用後可能造成的影響。
因此，存取控制的目的並不是單純「把權限關小」，而是在業務需求與安全風險之間取得適當平衡，使每一項權限都有合理的使用目的，也能清楚說明為什麼需要這項權限。
權限與資產管理也不是完成初始設定之後就結束。隨著組織調整、人員異動、專案推進以及系統變更，原本合理的資源歸屬與權限配置，都可能逐漸失去原來的合理性。
例如，專案結束後仍然保留的臨時權限、已經調職卻仍具備管理權限的人員，或因長期累積而逐漸擴大的權限範圍，都是企業經常面臨的情況。
因此，企業管理規範除了建立初始要求之外，也需要定期檢視資產與權限配置，確認目前的管理關係是否仍然符合實際需求，並持續識別未使用權限、過度授權以及異常配置。
在雲端環境中，隨著資源與權限數量快速增加，也可以透過 Cloud Infrastructure Entitlement Management（CIEM） 等工具協助分析權限配置，讓最小權限不只是規範上的要求，而能夠透過持續性的檢視與分析落實。
而當企業開始掌握資產、身分與權限之後，還需要進一步確認這些資源目前是否正常運作，以及環境中是否出現值得注意的活動。這也使得監控、日誌與安全觀測成為後續管理規範需要處理的重要面向。
企業管理規範的建立，需要從最基本的管理關係開始：先掌握環境中有哪些資源，再確認資源由誰負責、由哪些身分使用，以及這些身分應該擁有哪些存取權限。
這些要求看似基礎，卻是後續安全控制能否有效運作的重要前提。沒有清楚的資產資訊，就很難進行完整的管理；沒有明確的身分與責任歸屬，就很難追蹤操作與權限；而沒有合理的存取範圍，最小權限也只能停留在原則層面。
因此，企業管理規範並不是把大量安全控制堆疊在一起，而是先建立清楚的管理對象、責任關係與存取邏輯，再逐步延伸到監控、事件處理、復原以及其他安全要求。這些基礎管理關係越清楚，後續的安全治理也越容易落實與持續維護。
iThome鐵人賽
看影片追技術