用 Atlassian Guard （Standard）管好帳號：從 IdP 串接到 JSM Customer 授權問題

搞懂 SSO、AD 整合與帳號計費，避免資安漏洞與授權失控

為什麼帳號管理，會直接影響資安與費用？

在導入 Atlassian Guard（Standard）時，許多團隊會把它當成單純的 SSO 工具，但實務上它的核心其實是「帳號治理（Identity Governance）」。

這件事情之所以重要，是因為它同時牽動兩個關鍵面向。

第一是資安風險。如果帳號沒有被妥善管理，例如離職員工仍然保有登入權限，或外部協作帳號沒有設置適當限制，那麼即使系統本身安全性再高，仍然可能從「帳號」這個入口產生漏洞。

第二是成本控制。Guard 的計價是以 managed account（受管理帳號）為基礎，如果組織內存在重複帳號、未清理的歷史帳號，或是不必要被納管的外部使用者，最終都會反映在授權費用上，造成預期外的成本增加。

換句話說，帳號沒有管好，影響的不只是安全，也會直接影響預算。

Guard 與 IdP 的整合：責任分工要釐清

Atlassian Guard 本身並不是一個「帳號來源」，而是建立在 Identity Provider（IdP）之上的管理與治理層。

常見的整合對象包括 Microsoft Entra ID、Okta 或 Google。在這樣的架構下，可以將責任簡單拆成兩個部分：

• IdP 負責「身分驗證與帳號來源」
• Guard 負責「政策控管與安全治理」

這樣的分工如果沒有釐清，實務上就很容易出現只做了一半的情況。

Atlassian Guard 與 IDP 串接示意圖

SSO 與 Provisioning 是兩件不同的事情

在多數專案中，最常見的誤解是把 SSO 與帳號管理混為一談。

SSO（通常透過 SAML）解決的是「使用者如何登入」。當使用者存取 Atlassian 產品（例如 Jira）時，會被導向 IdP 進行驗證，驗證成功後再回到系統。

但這只解決了「登入流程」，並沒有處理帳號的生命週期。

帳號生命週期的管理，則是透過 SCIM Provisioning 來完成。這包含了使用者的建立、更新與停用，並且應該由 IdP 自動同步到 Atlassian 組織。

如果一個組織只做了 SSO，卻沒有導入 Provisioning，常見的結果是：員工離職之後，帳號仍然存在於系統中，只是沒有再被使用。這在稽核或資安角度來看，是一個相當明確的風險。

因此可以用一句話總結：

SSO 決定「誰可以登入」，Provisioning 決定「這個帳號是否還應該存在」。

JSM Customer 與 Guard 授權：最常見的誤解

在 Jira Service Management 的使用情境中，帳號類型會變得更加複雜，也更容易影響 Guard 的授權計算。

首先需要區分兩種帳號。

一種是 managed account，也就是屬於公司網域（例如 @company.com），並且已經完成網域驗證後被納入管理的帳號。這類帳號可以套用 SSO、MFA 等安全政策，同時也會被納入 Guard 的計費範圍。

另一種是 Portal-only customer，這類使用者通常是外部客戶，只透過 JSM portal 提交或查看請求，並不具備完整的產品使用權限。這類帳號在預設情況下不會被納入 Guard 計費。

問題通常出現在這兩者的界線被模糊時。例如，當外部使用者使用公司網域信箱，或被套用了 Guard 的安全政策時，就可能從「不計費」轉變為「需要計費的 managed account」。

Non-billable policy：控制成本的重要工具

在這樣的情境下，Non-billable authentication policy 會是一個非常實用的機制。

透過這個設定，可以將特定使用者（例如 JSM portal 客戶或部分外部協作人員）排除在強制 SSO 或 MFA 之外。這樣的設計有兩個效果：

第一，不影響這些使用者的使用體驗，特別是在他們不具備企業 IdP 帳號的情況下。

第二，避免這些帳號被納入 Guard 計費範圍，達到成本控管的目的。

但需要注意的是，一旦對這些帳號套用了安全政策（例如強制 SSO），它們就會被視為 managed account，進而產生費用。

為什麼 Trello 或 Bitbucket 使用者也會被計費？

另一個常見的問題是，企業只使用 Jira 或 Confluence，卻發現 Guard 的計費人數高於預期。

這通常是因為 Atlassian 帳號是跨產品共用的。例如 Trello 或 Bitbucket 的使用者，只要使用相同網域並被納入 managed account，就會一併計入 Guard 授權。

因此，Guard 的計費邏輯並不是「你用了哪些產品」，而是「有哪些帳號被你納入管理」。

實務建議：如何建立可控的帳號治理機制

在實務導入中，我們通常會建議從以下幾個步驟開始。

1. 盤點現有帳號結構。這包含 Atlassian 帳號總數、屬於公司網域的比例，以及哪些帳號實際需要被納入管理。
2. 明確區分帳號類型。內部員工應該套用完整的安全政策，外部協作人員則可以採取較彈性的控管方式，而 JSM 客戶則需要特別評估是否應該被納入管理範圍。
3. 確保 Provisioning 機制完整建立。這是避免帳號殘留與降低風險的關鍵，也是許多企業在初期最容易忽略的一環。
4. 定期檢視 Guard 的授權來源。包含是否有不必要的帳號被納入、是否有其他產品（如 Trello、Bitbucket）使用者影響計費。

Guard 的核心，是帳號治理能力

回到最根本的問題，Atlassian Guard 的價值並不只是提供安全功能，而是幫助企業建立一套可控、可稽核的帳號治理機制。

當組織只導入 SSO 時，改善的其實只是登入體驗；但當進一步建立 Provisioning、政策管理與帳號分類後，才真正進入可控的資安狀態。

你的團隊也對 Atlassian 的產品有興趣嗎？ 好奇如何進行敏捷工具導入與教育訓練嗎？ 瞭解更多細節 👉 請點擊此連結

✍️ 寫下你的需求 鈦坦科技 Atlasssian 團隊將有專人與你聯繫🫡