Atlassian Guard · 組織層級資安附加訂閱 Standard 建立存取的邊界，Premium 涵蓋邊界內的資料與行為Guard 將身分驗證、資料分級、內容偵測與事件回應整合於單一管理平面，對象為整個組織既有的 Jira 與 Confluence——系統，而是讓既有環境中的資料變得可治理、可稽核。
2 方案：Standard 與 Premium，Premium 疊加於 Standard 之上
60+ Premium 內建敏感內容偵測規則，並支援自訂規則
30 天 兩種方案均提供免費試用
80%+ Atlassian 企業雲端客戶已導入 Guard
導入背景
雲端協作平台，往往是資料治理最容易被略過的一段
多數組織已在端點防護、雲端存取安全代理與資安事件管理平台上投入相當資源，但 Jira 議題附件與 Confluence 頁面中的合約條款、客戶名單與系統憑證，通常未被納入同一套治理框架。常見的風險缺口集中於三類日常性疏漏，而非外部入侵：離職人員的存取權未即時解除、內部頁面被設定為公開連結、以及 AI 助理檢索到原本不應納入索引的內容。
Atlassian Guard 針對的正是這一段落差。Standard 建立身分與存取的邊界，Premium 則延伸至資料本身：內容於寫入當下即完成掃描與分級，異常行為在數分鐘內轉為告警，並提供可直接執行的修復建議。
− 95% 安全事件調查時間
Guard Standard 進階稽核記錄，使單次調查由 10–20 小時縮至約 30 分鐘
5 分鐘
每位使用者上下線節省時間
Guard Standard 依 IdP 群組自動授權與撤銷，取代逐人手動設定
230%
三年投資報酬率
Cloud Enterprise 整體之複合組織模型（內含 Guard Standard），非 Guard 單獨歸因
資料來源：Forrester Consulting TEI Spotlight 《Atlassian Guard Standard Saves Time While Securing Sensitive Information》 （Atlassian 委託），節錄自《The Total Economic Impact™ Of Atlassian Cloud Enterprise》（2025 年 6 月）。調查時間與上下線時間為受訪組織（其中一家為 5,000 名以上使用者之政府機關）的自述；ROI 為使用 Cloud Enterprise 之複合組織模型的估計值。數字非個別客戶承諾。
三個防護層次
隨組織規模擴充的防護能力
Atlassian Cloud 的資安能力分為三層，後者疊加於前者之上。釐清目前所處的層次，是選版判斷的起點。
Layer 1
Atlassian 平台
預設即具備
每個 Atlassian Cloud 方案均內含的基本身分與資料控制，包含站台層級的權限管理與產品自身的安全設定。無須額外訂閱。
Layer 2
Guard Standard
組織層級的可視性與控制
將控制範圍由單一站台提升至整個組織的所有帳號：強制單一登入與兩步驟驗證、SCIM 自動佈建、API token 管控，以及跨產品的稽核記錄。
Layer 3
Guard Premium
進階防護與威脅偵測
由存取層延伸至資料本身：資料分級與自動分類、內容掃描、異常行為偵測，以及告警調查與修復動作。適用於持有高價值資料的組織。
三大價值支柱
Protect · Detect · Respond
Guard 依「保護、偵測、回應」三個階段設計。Standard 涵蓋前段的存取控制與可視性，Premium 補齊資料層的偵測能力與事件回應機制。每個階段之下另有三項具體能力，並各附一段 Atlassian 原廠錄製的管理主控台操作畫面，共九項；影片點擊後才載入，不影響頁面初始載入速度。〈Atlassian Guard 是什麼？用 Protect / Detect / Respond 一次看懂企業級資安策略〉
主動防範資料外洩
透過彈性的政策設定，界定哪些人員、在何種裝置條件下，可對特定等級的資料執行哪些操作。
強制單一登入與兩步驟驗證 ，最多可建立 20 組驗證政策，分別套用於正職員工、約聘人員、外部協作者與服務帳號 SCIM（System for Cross-domain Identity Management）自動化佈建 ，於身分識別提供者停用帳號的同時解除存取權 行動應用程式管理 ，限制截圖、螢幕錄影與檔案下載 分級式資料政策 （Premium），依機密等級限制公開分享與匯出行為
Protect · 實際操作畫面
Standard · Premium
要求進階驗證
建立多組驗證政策，對受管帳號與外部協作者分別施加不同強度的控制。
Authentication policies 的政策設定頁，涵蓋單一登入、兩步驟驗證、第三方帳號登入、密碼強度、閒置逾時與 API token 管控。
Standard · Premium
保護團隊的工作內容
對分散各地的團隊強制單一登入，並套用行動應用程式管理。
Mobile app policy 的建立流程，可禁止分享、截圖與螢幕錄影，限制複製與下載，並要求生物辨識或裝置密碼與最低作業系統版本。
Premium
辨識關鍵資料
以資料分級降低資料外洩風險。
Create classification level 精靈，逐步設定等級名稱、代表色、定義，以及提供給使用者判讀的使用指引。
偵測可疑活動與資料誤用
將風險盤查從人工抽查，轉為持續性掃描與規則化偵測。
組織稽核記錄 ，完整保留管理員操作歷程（Standard） 使用者活動稽核與 API token 使用追蹤 （Premium）內容掃描 （Premium），60 項以上內建偵測涵蓋個人資料、金融資訊、憑證與健康資料，支援全站掃描與寫入當下的即時判定 產品探索 ，識別組織內未納管的 Atlassian 站台
Detect · 實際操作畫面
Standard · Premium
揭露異常行為
以稽核記錄檢視 Atlassian Cloud 上跨產品的活動歷程。
組織層級的 Audit log，可依日期、活動類型、行為者與來源 IP 位址交叉篩選，記錄範圍涵蓋過去 180 天，並可整批匯出。
Standard · Premium
降低 Shadow IT 風險
透過自動化的產品探索，識別組織內未經核准的 Atlassian 產品。
Discovered products 清單（示範環境中列出 137 個站台），逐項顯示使用者人數、建立日期、最後活動時間與現任管理員，可匯出 CSV，並於成員自行建立新產品時發出通知。
Premium
排序高風險威脅
以可自訂的偵測規則與告警，快速判讀組織當前的暴險範圍。
User activity detections 清單，逐項列出偵測規則、所屬產品與偵測間隔——匿名存取 Confluence、Confluence 頁面匯出、分類等級變更、資料安全政策變更等多數項目均為即時（Real Time）判定。
Respond · 實際操作畫面
Premium
集中檢視告警
以單一檢視掌握頁面匯出、可疑登入等使用者行為。
告警儀表板，含登入來源的地理位置地圖、告警與活動的每日趨勢圖，以及可依告警類型、活動、產品與狀態篩選的活動明細表。
Premium
加速事件回應
透過 SIEM（Security Information and Event Management）整合，於數分鐘內將潛在威脅通知資安團隊。
「Confluence page crawling」告警詳情，列出遭檢視的頁面及其分類等級、行為者脈絡（IP 位址、地點、帳號建立時間）、事件時間軸與建議調查步驟，並可就地開立 Jira 議題轉入既有的事件處理流程。
Premium
有效解除威脅
偵測到威脅時，直接執行系統建議的修復動作，例如停用帳號。
「Confluence 可疑搜尋行為」告警，以圓環圖呈現同一使用者於 30 分鐘內搜尋的敏感關鍵字分類（存取權杖、憑證、RSA 金鑰），並於下方直接提供停用帳號、調整空間權限與撤銷 API token 三項修復選項。
生態系整合
將 Guard 整合至既有的資安架構
告警與稽核記錄可送往組織既有的資安工具，無須為 Guard 另建一套作業流程。整合分為三類：
身分識別提供者
透過 SAML（Security Assertion Markup Language）或 OIDC（OpenID Connect）串接，並以 SCIM 同步帳號的建立與停用。
告警通知
可疑活動命中偵測規則後，將告警送至團隊既有的通訊管道。
資安事件管理平台
稽核記錄可經 Webhook 與 API 串流至 SIEM，納入既有的監控與留存機制。
身分與存取
Guard 與身分識別提供者如何協作
Guard 不自行保存密碼，也不另建帳號目錄：登入交給公司的 Identity provider 驗證，帳號與群組則由 IdP 單向同步進 Atlassian 組織。圖一與圖二分別說明「登入的那一刻」與「帳號從到職到離職的生命週期」。
登入時：以公司 IdP 進行 SSO
使用者以公司的 Identity provider（Okta、Microsoft Entra ID、Google Workspace）登入，密碼原則與多因素驗證要求由 IdP 統一控管，Atlassian 端不另存密碼。首次登入時自動建立 Atlassian 帳戶，之後每次登入皆套用 IdP 當下的驗證設定。
Identity provider 統一控管密碼與驗證 Atlassian 組織 Atlassian Guard SSO · 帳號佈建 · 全組織洞察
圖一：SSO 登入流程。Guard 作用於組織層級，Jira 與 Confluence 等所有站台一併納入，不需逐站台設定。
帳號生命週期：以 SCIM 同步群組
IdP 群組的成員異動會自動同步至 Atlassian 組織的 Directory，再套用至各 Cloud site，與站台既有群組並存。於 IdP 停用的使用者會同時在所有站台失去存取權，不需逐站台處理，帳單人數也隨之下降。〈用 Atlassian Guard（Standard）管好帳號：從 IdP 串接到 JSM Customer 授權問題〉
Identity provider 以群組指派存取權 Atlassian 組織 Cloud site 1 既有站台群組 ＋ Synced groups Cloud site 2 既有站台群組 ＋ Synced groups
圖二：SCIM 佈建流程。Synced groups 的成員僅能於 IdP 端修改，Atlassian 端為唯讀，確保單一事實來源。
兩張圖對應導入路線圖的步驟 2 與步驟 3；切換 SSO 前的測試政策與緊急管理帳號等注意事項，見導入路線圖 。
受管帳號
Guard 如何把帳號收進組織的控制範圍
Atlassian 帳號隸屬於人，而非任何單一產品。Guard 先由組織驗證其擁有的電子郵件網域（Claimed domain），再把使用該網域的帳號納為受管帳號（Managed accounts）；驗證政策、密碼原則與 API token 管控隨之套用在帳號本身，而非逐站台設定。圖三以 Acme Global 為例：兩個已驗證網域的帳號進入納管，供應商網域的帳號留在範圍之外。
Your organization · Acme Global Managed accounts
@acme.com Claimed accounts acme.atlassian.net Cloud site · Jira · Jira Service Management · Confluence
@acme.co.uk Claimed accounts acme-eu.atlassian.net Cloud site · Jira · Confluence
@vendor.com Accounts with another domain 未納管
安全設定自動套用： 驗證政策、密碼原則、閒置逾時與 API token 管控，對所有 Managed accounts 一體生效，不需逐站台設定。 登入方式受控： 可阻止受管帳號改用第三方帳號登入，一律由公司 IdP 驗證。 外部協作者另行處理： 其他網域（如 @vendor.com）的帳號不在納管範圍，須以外部使用者政策施加控制。
圖三：Guard 以 Claimed domain 為界，將 @acme.com 與 @acme.co.uk 的帳號收入 Acme Global 的 Managed accounts；帳號屬於人而非產品，因此控制施加於帳號，即涵蓋其可存取的所有 Cloud site。
產品方案與 Guard 的分工
已經有 Jira，為什麼還需要 Guard？
兩者的作用範圍不同 。Jira 與 Confluence 方案中的安全控制，範圍為單一站台與單一產品，處理的是應用程式的存取條件 ；Atlassian Guard 的範圍為整個組織的所有帳號與所有 Atlassian 產品，處理的是身分與資料本身 。兩者為並行的訂閱，升級 Jira Premium 不會取得 Guard 的任何能力，反之亦然。
為何產品方案無法取代 Guard： Jira Premium 的 IP 許可清單僅於站台層級 生效，依官方文件不涵蓋 admin.atlassian.com 與帳號管理的 REST API。更根本的是，Atlassian 帳號不隸屬於任何單一產品 ——在 Jira 移除離職人員的存取權後，帳號依然存在、依然可登入，且可能仍持有其他站台的權限。未經 Guard 納管，就無法強制其改用公司 IdP 登入，也無法在 IdP 停用時連動解除全部存取權。
判斷功能歸屬的依據： 於站台管理區設定的項目屬於 Jira 或 Confluence 方案；須於 admin.atlassian.com 設定的項目屬於 Guard。組織層級的管理面不在單一站台的權責範圍內，升級產品方案不會涵蓋。
完整功能對照
Guard Standard 與 Guard Premium 的差異
Premium 為疊加於 Standard 之上的方案，並非替代選項。Guard Standard 已內含於 Cloud Enterprise，以及 Teamwork Collection 的 Premium 與 Enterprise 方案；上述訂閱的持有者在升級 Premium 時，僅需補足每位使用者的價差。
✓ 內含EA = Early Access
選版的判斷基準： 核心課題若是「帳號如何取得與解除存取權」，Standard 即可滿足；若是「內容中有哪些不該存在的資料、何人於何時存取過、能否即時處置」，則僅 Premium 具備對應能力——後者正是受監管產業於稽核時被要求說明的項目。
重點能力說明
對照表中幾項需要進一步理解的機制
對照表以單行呈現各項能力，但其中六項的實際運作方式會直接影響導入工作量與選版判斷。
Premium
資料分級與自動分類
Guard Premium 於組織層級提供 Public、Internal、Confidential、Restricted 四級標籤，套用對象為 Confluence 頁面與 Jira 議題。標籤本身不具強制力 ：將頁面標為 Restricted 不會自動封鎖任何操作，必須另行建立「以分類等級為條件的組織級政策」，該等級才會實際限制分享與匯出行為。
自動分類則於內容寫入時比對敏感樣式，命中信用卡號等格式即自動套用對應等級，用以降低仰賴人工標記所產生的落差。導入順序通常為先以手動分級建立少量高價值內容的基準，再逐步開啟自動分類。初期誤判比例過高時，標籤的可信度會連帶受影響。
資料安全政策
可限制匯出、公開分享連結、匿名存取與第三方應用程式的資料存取，兩種方案均具備。差別在於套用條件 ：Standard 以空間或專案為範圍，屬一體適用；Premium 則可將分類等級作為條件，例如「Confidential 以上一律封鎖對外分享連結，Internal 以下不受限」。
此項為兩方案的主要分野。若安全要求可以「整個空間全開或全關」表達，Standard 即可滿足；若必須依內容本身的敏感程度採取不同管制，才需要 Premium 的分級能力。
內容掃描與自訂偵測規則
內容掃描提供 60 項以上內建偵測，涵蓋個人資料、金融資訊、憑證與健康資料，並以兩種模式運作：全站掃描對既有內容執行一次性盤點，即時掃描則於內容寫入當下判定。
內建偵測以國際通用格式為主 （信用卡號、雲端服務金鑰、美國社會安全號碼等）。台灣的身分證字號、健保卡號與統一編號不在預設清單內，須以自訂偵測規則建立。此項工作量需納入導入時程評估。另有兩項涵蓋限制：掃描不執行光學文字辨識，亦不涵蓋附件內容；以掃描檔形式流通文件的組織，實際覆蓋率會低於偵測項目數所呈現的水準。
Standard · Premium
稽核記錄的兩個層次
兩者的記錄對象不同：Standard 記錄管理員的操作行為，Premium 另涵蓋使用者對內容的檢視與匯出行為。
兩者各自涵蓋哪些操作、保留多久，逐項對照見本節下方的稽核記錄對照 。
告警、調查與修復動作
可疑活動偵測涵蓋異常登入、大量匯出與資料外洩徵兆，命中後於統一的調查儀表板呈現，包含行為者脈絡與事件時間軸，免去跨多個管理介面拼湊事件經過。告警可送達 Slack 或 Microsoft Teams，稽核記錄亦可經 Webhook 與 API 串流至 Splunk 等資安事件管理平台。儀表板並提供可直接執行的修復動作：停用帳號、遮蔽敏感內容、重新分類。
告警機制的效果取決於收斂程度，而非偵測規則的數量。 上線前需設定告警等級與接收對象，並訂定高風險項目的處理時限。未經分級的情況下，未處理告警的累積會使儀表板失去判讀價值。
AI 治理
兩項能力目前均屬 Early Access，官方產品頁另標示為 coming soon：Rovo Chat 的提示與回應內容掃描，可阻擋或遮蔽出現於 AI 對話中的敏感資料；連接器資料安全則避免第三方來源的敏感資料被納入 Teamwork Graph 的索引範圍。
Early Access 階段的功能不宜列為既有保障 ；三道邊界怎麼設、哪些已正式提供，見AI 治理 。
稽核記錄：兩種方案分別記錄什麼
離職人員的存取歷程盤查，或稽核單位要求說明「何人於何時檢視過哪份文件」這類需求，僅憑 Standard 的管理員記錄無法完成。
Standard 管理員活動日誌
記錄管理員層級的操作，回答「誰動了組織設定」。
Authentication policy 的建立、修改、刪除
使用者帳號的新增、停用、移除
產品存取權限與群組成員變更
Marketplace App 的安裝與移除
資料安全政策的調整
API token 的撤銷
組織洞察（Insights） ：每日／每月活躍使用者、授權使用狀況、已啟用兩步驗證或 SSO 的受管帳號比例。
保留期限：最多 180 天。
Premium 使用者活動日誌 + 進階整合
在 Standard 之上額外記錄一般使用者的操作，並可即時串流至 SIEM。額外記錄範圍：
使用者建立、編輯、刪除頁面／Issue
使用者匯出資料（PDF、CSV）
使用者存取特定空間／專案的紀錄
使用者的登入／登出事件與 IP 位址
異常行為事件（大量下載、非正常時段存取等）
更細緻的篩選 ：可依使用者、產品、操作類型、時間區間交叉查詢。
保留期限：官方文件載明最多 180 天，未區分方案；更長期的留存需定期匯出或串流至 SIEM。
資料分類四級
四個等級分別對應什麼內容，又實際限制了什麼
資料分類為 Guard Premium 與 Standard 之間最明確的差異所在；惟等級名稱本身不具效力，實際限制須由資料安全政策賦予。等級的數量與名稱可由組織自行定義，本節以 Atlassian 預設的四級架構說明。
Level 1
Public
已確認可對外揭露的內容，不含任何未公開資訊。
典型內容 對外發布的產品說明、公開技術文件、行銷素材、徵才資訊、已發布的新聞稿。
套用政策後 允許匿名檢視與公開分享連結，匯出與第三方應用程式存取均不受限。此為唯一預期會以公開連結流通的等級。
容易忽略的一點 未分類的內容不等於 Public。 未帶標籤的頁面不會被視為公開，但同樣不受任何分級政策約束——這是導入初期覆蓋率必須先行盤點的原因。
Level 2
Internal
限組織成員檢視的日常工作內容，多數頁面與議題屬此級。
典型內容 專案規劃、會議記錄、內部流程與教育訓練文件、一般開發議題與技術討論。
套用政策後 封鎖對外公開分享連結與匿名存取；組織內部成員的檢視、編輯與匯出行為不受限制。
容易忽略的一點 此級適合作為導入初期的基準等級：先以 Internal 涵蓋大多數內容，再往上分出少量高敏感內容 ，比一開始就建立細緻的分級規則更容易維持。
Level 3
Confidential
外流將造成商業或法遵損害，僅限特定團隊或角色接觸。
典型內容 報價與定價策略、合約條款、客戶名單、財務數據、尚未公布的產品規劃、個人資料檔案。
套用政策後 於 Internal 的限制之外，另禁止匯出（PDF、Word、CSV 等格式）與第三方應用程式讀取內容。
容易忽略的一點 此級是自動分類的主要落點：內容掃描命中信用卡號、雲端服務金鑰等樣式時會自動升級至此。台灣的身分證字號、健保卡號與統一編號不在內建的 60 餘項偵測清單內 ，須自行建立自訂偵測規則，此工作量應納入導入時程。
Level 4
Restricted
僅限最小必要範圍存取，任何一次未授權檢視都須留下記錄。
典型內容 系統憑證與 API 金鑰、法務與併購文件、人事調查資料、資安事件記錄、受監理規範約束的客戶資料。
套用政策後 於 Confidential 的限制之外，另禁止外部協作者存取，並可將內容排除於 Rovo 等 AI 助理的檢索範圍。命中偵測規則時觸發告警，並於調查儀表板提供建議修復動作：停用帳號、遮蔽敏感內容、重新分類。
容易忽略的一點 分類標籤依附於內容本身，而非其所在的 Space 或專案。 標為 Restricted 的文件無論被移至何處，均受同一套政策約束——這正是分級相對於空間權限設定的主要價值。
適用說明： 一、分類標籤本身不具強制效力，上述限制須於組織層級另行建立「以分類等級為條件的資料安全政策」，方能生效。二、此處列舉之限制為常見的政策設定範例，並非產品預設值，實際行為以組織所建立的政策為準。三、分級式資料政策為 Guard Premium 專屬；Guard Standard 的資料安全政策以空間或專案為套用單位，於其範圍內一體適用。相關差異詳見功能對照表 ；政策如何選定範圍與疊加，見下一節資料安全政策 。
資料安全政策
讓標籤產生實際限制：一組政策 ＝ 範圍 × 規則
分類標籤只是內容上的註記，實際限制由組織層級的資料安全政策執行。一組政策只有兩個要件：管到哪些資料 （覆蓋範圍）與不允許做什麼 （規則）；名稱、描述、建立者與啟用狀態則是一般的管理欄位。政策建立於組織層級，同一組規則可跨 Jira 與 Confluence 一致執行，單一組織最多可建立 50 組。
以下以一組名為 Finance data 的政策為例。財務團隊的預算表與稽核底稿分散在 Jira 議題與 Confluence 頁面，管理者不想逐一空間設定，於是把範圍定為兩個產品的全部內容 ，規則只挑兩項：禁止匯出、禁止建立公開連結（圖四）。
Finance data財務與稽核內容的保護政策 · 建立者 IT Security
Active
覆蓋範圍 Coverage
管到哪些資料？
Jira Confluence
以「整個產品」為範圍——兩個產品內的所有頁面與議題都受此政策約束。
規則 Rules
不允許做什麼？
✕ 匯出資料 Data export ✕ 建立公開連結 Public links · Confluence
圖四：Finance data 生效後，Jira 與 Confluence 內的任何頁面或議題都無法匯出為 PDF、Word 或 CSV，也無法產生公開分享連結；未勾選的「匿名存取」與「應用程式存取」則不受此政策影響。範圍決定「管到哪些資料」，規則決定「不允許做什麼」——下方分別說明範圍的三種選法，以及多組政策同時涵蓋同一內容時的效果。
覆蓋範圍怎麼選：三種方式
三種方式的差別在於用什麼當邊界 ：整個產品、特定的空間與專案，或內容本身的分類標籤。前兩種 Standard 即可使用；依分類等級劃定範圍是 Premium 專屬，也是「資料分級」一節之所以重要的原因。
匿名存取 僅 Jira Anonymous access 阻擋未登入者檢視覆蓋範圍內的內容。 匯出資料 Data export 阻擋匯出 Confluence 頁面、部落格與 Jira 議題。 公開連結 僅 Confluence Public links 禁止為覆蓋範圍內的頁面建立公開分享連結。
應用程式存取 僅空間／專案 App access 阻擋 Marketplace 與自訂應用程式讀取特定資料。
多組政策疊加：同一站台落在兩組政策內時
舉例：Acme 組織有五個 Confluence 站台，資安團隊基於兩種不同的顧慮各建一組政策。Policy 1 針對含個人識別資訊（PII）的站台——hr 與 legal——規則最嚴：不允許下載、應用程式存取與匿名存取。Policy 2 針對含未經核准對外揭露資訊的站台——finance、hr、legal 與 marketing——只禁止下載與匿名存取。設定；hr 與 legal 因同時符合兩種顧慮而落在兩組範圍內。
下表逐站台列出涵蓋情形（✓ 表示受該政策約束），最後一欄是實際生效的限制 ：所有涵蓋該站台的政策，其規則加總。
怎麼讀這張表： hr 與 legal 同受兩組約束，實際限制是兩組規則的加總——Policy 2 沒有限制應用程式存取，但這兩站仍被 Policy 1 阻擋；finance 與 marketing 只受 Policy 2 約束；主站 acme.atlassian.net/wiki 不在任何政策範圍內，完全不受限。實務上建議先以「整個產品」或「指定空間／專案」建立全組織的底線政策，再以「依分類等級」的政策針對高敏感內容加嚴。
AI 治理
導入 AI 前，先讓 AI 只讀得到該讀的
AI 依提問者既有的權限回答問題，這是設計上的保障。從未分級的頁面與工單：維持的隱蔽性，在 AI 檢索面前不再成立。政策與帳號管控，正是讓 AI 可以放心全面開放的前提。
三道要先設好的邊界
對話中的敏感內容
情境 同仁在 Rovo Chat 提問，回答可能引用含個資或機密的頁面；也可能把憑證或客戶資料直接貼進提示。
Guard 對應 Rovo Chat 提示與回應掃描：對話文字比對內容掃描的偵測規則，命中即阻擋或遮蔽，對話得以繼續。
檢索範圍
情境 Rovo 與 connector 會把 Jira、Confluence 及 Google Drive、SharePoint 等外部來源納入 Teamwork Graph；權限過寬的頁面與外部文件都可能成為答案的來源。
Guard 對應 分類標籤標出 Restricted 內容，資料安全政策限制其匯出、公開連結與應用程式存取；Rovo 依權限回答，收斂 Restricted 的檢視權限即縮小檢索範圍。connector data security 則在外部文件進入索引前比對偵測規則並阻擋。
狀態
分級與政策 正式提供 Premium
connector data security Early Access Premium
非 Atlassian 的 AI 工具
情境 團隊以 AI 編碼助理等第三方工具，透過 REST API 或 Rovo MCP server 讀取 Jira 與 Confluence；若以個人帳號授權，工具的可見範圍等同該同仁，且離職後仍可能持續有效。
Guard 對應 以 service account 取代個人帳號授權；API token 到期與建立限制政策；資料安全政策的應用程式存取與 MCP server 存取規則、允許連線的 AI 工具網域；稽核記錄可見每次工具呼叫與讀取範圍。
狀態
帳號授權與存取控制 正式提供 Standard
API token 使用追蹤與建立／撤銷告警 正式提供 Premium
導入 AI 前先做的三件事
先開內容掃描盤點既有敏感內容，並標示分類等級。
收斂 Restricted 的檢視權限縮小 AI 可見範圍，並禁止匯出與公開連結。
AI 工具一律以 service account 與有到期日的 API token 授權，納入稽核記錄。
對應場景： 「Rovo 上線第二週，有同仁詢問本年度調薪級距」見通用場景 ；「開發團隊導入 AI 編碼助理」見軟體開發場景 。Early Access 功能的可用性與範圍可能調整，正式導入前建議於試用期間驗證。
場景對照
同一事件發生時，兩種方案分別能處理到什麼程度
部分差異在功能清單上不易呈現，須於事件發生時方會顯現。以下二十一個場景取自實際運作中反覆出現的類型：先列出跨產業通用情境，其後依金融保險、製造半導體、專業服務、醫療與公部門、軟體開發等產業分組。兩方案的差異不在於能否防範，而在於事後能否完整說明事件經過，以及從發現到處置所需的時間。
通用 5
金融保險 3
製造半導體 2
專業服務 3
醫療公部門 2
軟體開發 6
通用場景5 則
資深工程師於週五提出離職，主管在下週一才開始盤查其存取歷程
該員於最後兩週仍持有 Confluence 技術規格庫的完整存取權。人資已於身分識別提供者停用帳號，但主管需要釐清的是：離職前該段期間內，其實際匯出與下載了哪些內容。
兩方案的處理程度 ✓ Premium
SCIM 會在身分識別提供者停用帳號的同時解除 Atlassian 存取權，此環節可完整覆蓋。惟稽核記錄僅涵蓋管理員操作 ，可查得權限設定的變更歷程，但無法回溯特定使用者的檢視與匯出行為。實務上僅能依靠頁面版本紀錄逐頁比對，而匯出行為本身並未留存記錄。
✓ Guard Premium使用者活動稽核記錄會保留該員的檢視與匯出行為，可直接匯出完整時間軸供調查使用。若事前已配置大量匯出的偵測規則，此行為在離職前即會觸發告警 ，而非於事後才展開追查。
行銷同仁將一頁 Confluence 設定為公開連結，該頁包含尚未對外的定價資訊
其原意是分享給外部設計協力廠商，因而選擇了「知道連結的人皆可檢視」。三週後，業務單位在客戶端看到了這份定價資料。
兩方案的處理程度 ✓ Premium
資料安全政策可於站台層級全面禁止公開連結 ，但此設定為全有全無：一旦啟用，行銷本應對外公開的活動說明與產品文件亦同時受限。此類設定多因業務單位反映而重新開放，難以長期維持。
✓ Guard Premium改以分類等級作為管控條件 ：標示為 Public 的行銷素材維持正常分享，Confidential 以上則一律禁止公開連結與匯出。定價資料因命中偵測規則而自動升級分類，該同仁在執行分享操作的當下即被阻擋，而非於三週後才由業務單位回報。
稽核單位要求說明：Confluence 中是否存有客戶的身分證字號
依內部規範不應存在，但組織共有 40 個 Space、累積六年的內容，且客服團隊過去確有將個案截圖與資料貼入頁面的作業習慣。此項目須於兩週內提出書面答覆。
兩方案的處理程度 ✓ Premium
不具備內容層的盤查能力，僅能透過 Confluence 搜尋配合人工抽查。此種作法在稽核程序中難以構成充分證據，能夠證明的是「已進行查找」，而非「已完成全面掃描」。
✓ Guard Premium可運用內建的個人資料偵測，搭配自訂規則 （例如台灣身分證字號格式），執行一次全站掃描並產出命中清單與所在頁面，後續可套用遮蔽或重新分類的修復動作。新增內容則於寫入當下即完成判定。惟須先確認覆蓋範圍： 掃描不含光學文字辨識、不涵蓋附件內容，亦不支援 Confluence Whiteboard。若前述截圖為影像格式，本輪掃描無法涵蓋。
凌晨時段，某帳號自非慣用地點登入，隨後開始大量下載附件
該員工的密碼曾於其他網站的外洩名單中出現，且在多處重複使用。攻擊者取得的是一組合法憑證，其行為在驗證層面完全合規。
兩方案的處理程度 ✓ Premium
強制單一登入（Single Sign-On）與兩步驟驗證（Two-Step Verification）可大幅降低此類攻擊的成功率，構成第一道防線。惟若攻擊者已突破兩步驟驗證，Standard 不會產生任何告警 ，事件通常需數日後才會被察覺。
✓ Guard Premium可疑活動偵測可辨識異常登入與大量下載的組合行為，於數分鐘內將告警送至 Microsoft Teams、Slack 或資安事件管理平台。告警本身即附帶行為者脈絡與事件時間軸，並提供停用帳號 的建議動作，資安人員可於同一介面完成處置。
Rovo 上線第二週，有同仁詢問本年度調薪級距，系統提供了完整答覆
資料來源為人資兩年前建立的一頁 Confluence，當初的權限設定開放給全公司，後續無人重新檢視。AI 並未執行任何違規操作，僅是呈現了原本即處於開放狀態的內容。
兩方案的處理程度 ✓ Premium
AI 的可見範圍等同於既有的頁面權限，而權限的設定偏差多為長期累積的結果。Standard 不具備盤點「哪些高敏感內容的權限範圍過寬」的能力，此類問題通常須待實際被查詢後才會浮現。
✓ Guard Premium內容掃描可在 AI 導入前先行盤點出此類頁面並標示為 Restricted，管理者據此收斂頁面權限，Rovo 依權限回答的範圍隨之縮小；資料安全政策可同時禁止匯出與公開連結。另提供 Rovo Chat 的提示與回應掃描（Early Access ），可於對話層阻擋或遮蔽敏感內容。三道邊界的設定順序見AI 治理 。
金融／保險業場景3 則
主管機關金檢要求提出某份風險評估報告近半年的完整存取軌跡
該報告存放於權限受限的 Confluence Space，權限清單本身可自設定頁調出。惟金檢問項為「實際開啟過該文件的人員與時間」，與權限清單並非同一件事。答覆期限為十個工作日。
兩方案的處理程度 ✓ Premium
稽核記錄涵蓋的是管理員操作 ——權限何時被授予、由何人授予——可完整證明存取權的設定歷程，但無法回答「權限清單上的三十人之中，實際開啟過該文件者為何人」。以權限清單代替存取軌跡提交，於金檢程序中通常會被要求補件。
✓ Guard Premium使用者活動稽核記錄逐筆保留檢視、編輯與匯出事件，可依內容與期間篩選後直接匯出，作為答覆的附件。事件亦可持續外送至資安事件管理平台長期保存，使舉證能力不受平台端保留期限的限制。
個資落地
理賠人員為加速跨部門協作，將保戶身分證字號與信用卡號貼入 Jira 工單
該工單歷經三個處理階段、七位經手人，並曾以通知信形式寄出。作業本身合乎既有流程，問題在於這些欄位原不應離開核心系統。
兩方案的處理程度 ✓ Premium
Standard 不檢視工單內容，此類資料進入 Jira 之後即無從辨識。多數組織依靠教育訓練與作業規範加以約束，惟在結案時效的壓力下，此種約束的實際遵循率既難以量測，亦無數據可供佐證。
✓ Guard Premium內建偵測涵蓋信用卡號與個人識別資訊樣式，並可另行建立台灣身分證字號的自訂規則 。工單於儲存當下即命中，可自動遮蔽該段內容並通知法遵窗口。既有工單則以一次性全站掃描盤出，產出可直接交付的命中清單。
併購案前置作業於 Confluence 建立專案 Space，交易消息尚未對外公開
核心小組共九人，但該 Space 建立時沿用了既有範本的權限設定，公司內另有二十餘人具備繼承而來的存取權。消息若於公開前走漏，組織須說明接觸範圍。
兩方案的處理程度 ✓ Premium
權限收斂屬 Space 管理層次，Standard 可確保僅經身分驗證的員工得以進入，卻無法辨識「此 Space 的內容敏感度與其權限範圍不相稱」。設定偏差須待人工複查方能發現，而併購案的時程通常不容許此種節奏。
✓ Guard Premium分類使敏感度附著於文件本身：標示為 Restricted 後，即可自組織層級一併禁止匯出、公開連結與外部協作者存取，不因單一 Space 的權限疏漏而失效。消息若確實外流，使用者活動稽核記錄可列出公開前曾檢視該內容的人員名單，此為向主管機關與律師說明時唯一具備效力的依據 。
製造／半導體業場景2 則
為協同開發新機種，三家供應商的工程師進入同一個共用 Confluence Space
該 Space 內除新機種規格外，另存有既有產品的 BOM 表（Bill of Materials，物料清單）、製程參數，以及一份委外代工的報價比較。三家供應商彼此互為競爭關係。
兩方案的處理程度 ✓ Standard✓ Premium
✓ Guard Standard此層級 Standard 已可覆蓋：外部使用者政策允許對這批帳號單獨套用規則，包括強制兩步驟驗證、縮短工作階段逾時、禁止建立 API token，並於行動裝置上停用下載與截圖。合作結束時可透過 SCIM 一次性回收。
✓ Guard PremiumPremium 補強的是內容誤置時的第二道防線。BOM 表與報價比較標示為 Restricted 後，即使被移入共用區域，外部協作者仍無法開啟。合作期間的檢視紀錄亦得以保留：供應商若質疑報價條件遭他方取得，組織具備可查證的回應依據，而非僅能表示「應該沒有」。
資深製程工程師離職三個月後，任職於直接競爭對手
公司懷疑其離職前已取得關鍵製程參數，擬循營業秘密相關法規主張權利。訴訟的第一道門檻並非證明對方使用了資料，而是證明該員曾接觸何種資料、於何時、以何種方式取出。
兩方案的處理程度 ✓ Premium
SCIM 已於離職當日完成帳號停用，此環節並無缺漏。惟舉證所需的是離職前數月的行為紀錄，而 Standard 的稽核範圍不含使用者的檢視與匯出。此時常見的作法是自備份資料與頁面版本紀錄反推，其完整度與證據強度均相當有限。
✓ Guard Premium使用者活動稽核記錄本即為此類需求而存在：可依人員與期間篩選，匯出含時間戳記的檢視與匯出事件清單。若事前已設定大量匯出的偵測規則，該行為在離職程序啟動前即已產生告警——組織得以在資料離開之前介入，而非於三個月後蒐集證據 。
專業服務／受稽核組織場景3 則
一位顧問先後接手兩家競爭客戶的專案，兩案的 Space 皆仍保留其存取權
依委任契約，組織須維持資訊隔離。人員調動由專案端自行處理，並無系統機制確保舊案權限同步解除。
兩方案的處理程度 ✓ Premium
權限的授予與解除均可執行，惟 Standard 無從判斷「同一人同時持有兩個互斥專案的存取權」屬於異常狀態。此類衝突須仰賴專案經理主動申報，而在人力調度緊湊的期間，最容易被略過的正是這道程序。
✓ Guard Premium兩案內容分別套用不同分類等級後，跨案的匯出與對外分享即受政策約束。真正的關鍵在事後：客戶若提出質疑，使用者活動稽核記錄可具體回答該顧問在轉調之後是否再度開啟過前案內容。此一答案，與「我們的政策規定不得如此」在專業責任的認定上有本質差異。
客戶年度供應商資安審查，問卷要求說明資料外洩防護與使用者活動軌跡的實作方式
前面數十題以政策文件即可答覆，此題則要求提出實際的機制說明與樣本輸出。審查未通過者將自合格供應商名單中移除。
兩方案的處理程度 ✓ Premium
Standard 能佐證的是存取控制層：單一登入、兩步驟驗證、外部使用者規範、帳號生命週期管理，這些項目通常可順利通過。但在資料外洩防護與使用者層稽核兩欄，僅能填列「以內部流程規範管理」，於審查中屬於明確的缺項。
✓ Guard Premium內容掃描與分類政策構成可展示的資料外洩防護機制，使用者活動稽核記錄則可直接輸出樣本作為佐證。對於以 SOC 2 或 ISO 27001 作為銷售前提的組織，此處的支出實質上並非資安成本，而是取得投標資格的條件 。
跨客戶隔離
專案經理將客戶 A 的系統規格文件移入共用 Space 作為範本，客戶 B 的窗口亦具該 Space 存取權
組織與雙方均簽有保密協議。此行為本身可能僅是一次文件整理，但若客戶 A 提出查詢，組織必須能明確說明何人於何時檢視過該文件。
兩方案的處理程度 ✓ Premium
Space 權限設計再嚴謹，仍無法防範內容被主動移至權限範圍較寬的位置。事後追查時，Standard 的稽核記錄僅涵蓋管理員操作，無法回應「哪些人員檢視過該頁面」。
✓ Guard Premium分類標籤依附於內容本身而非所在的 Space，標示為 Restricted 的規格文件無論移至何處，均受同一套政策約束。若事件確實發生，使用者活動稽核記錄可列出完整檢視紀錄，此紀錄為對客戶說明時的佐證依據。
醫療／公部門場景2 則
稽核發現研究團隊將受試者的病歷號與檢驗報告貼入 Confluence 進度頁
其中部分為文字表格，部分為自院內系統擷取的畫面截圖。組織須確認影響範圍，並提出後續的處置與預防措施。
兩方案的處理程度 ✓ Premium
不具備內容層的辨識能力。此類資料一旦寫入頁面即與一般內容無異，僅能以人工逐頁檢視，於數十個 Space、數年累積的內容規模下並不可行。
✓ Guard Premium文字形式的病歷號與檢驗數值可由自訂規則涵蓋，掃描後產出命中清單並套用遮蔽動作，新增內容則於寫入當下完成判定。惟此處的邊界須於選型階段即予認知： 內容掃描不執行光學文字辨識、不涵蓋附件內容，亦不支援 Confluence Whiteboard。以截圖形式存在的檢驗報告，本輪掃描無法辨識，該部分仍須以流程管制與人工複查處理。
民眾陳情案件以 Jira Service Management 受理，工單內含姓名、聯絡方式與案件描述
依個資法規範，此類資料應於處理目的完成後停止利用。實務上工單永久留存，且查詢權限開放給整個承辦科室。
兩方案的處理程度 ✓ Premium
可確保僅經身分驗證的人員得以進入系統，並限制外部存取，此為必要的基礎。惟「哪些工單含有個人資料」與「這些工單目前開放給何人」二者，Standard 均無法回答，年度個資盤點因而只能以抽樣方式進行。
✓ Guard Premium掃描可標定含個人資料的工單並依敏感度分類，據以套用禁止匯出與限制分享的政策。逾保存期限者可套用遮蔽動作，在保留案件處理歷程的同時移除個資欄位 。盤點結果可直接作為個人資料檔案安全維護計畫的佐證文件。
軟體開發／產品公司場景6 則
工程師為協助同事重現問題，將一組 AWS access key 貼入 Jira 留言
該議題共有 12 位關注者，其中兩位為外部協力廠商。問題排除後未有人回頭清除該則留言，內容持續留存於議題中。
兩方案的處理程度 ✓ Premium
此情境不在 Standard 的能力範圍內。Standard 管理的是存取層，不檢視議題的內容本身。此類憑證通常須待實際遭到濫用，或於下一次資安健檢的人工抽查中才會被發現。
✓ Guard Premium內建偵測涵蓋憑證與金鑰類樣式，留言於寫入當下 即會命中並觸發告警，可直接套用遮蔽的修復動作。惟涵蓋範圍須予釐清： 內容掃描僅支援 Jira 與 Confluence，不包含 Bitbucket 。程式碼中的硬編碼憑證仍須由專用的 secret scanning 機制處理。
承接大型專案，外包團隊 20 人將於下週進入組織的 Jira 與 Confluence
其存取範圍應僅限於該專案，但 Confluence 中同時存有其他客戶的規格文件、內部架構圖，以及一份載明各環境連線方式的維運手冊。
兩方案的處理程度 ✓ Standard✓ Premium
✓ Guard Standard此層級的需求 Standard 已可覆蓋：外部使用者政策允許對這 20 人套用獨立規則，包括強制兩步驟驗證、縮短工作階段逾時、禁止建立 API token，以及在行動裝置上限制下載與截圖。專案結束時可透過 SCIM 一次性完成權限回收。
✓ Guard PremiumPremium 補強的是 Space 權限設定發生疏漏時的第二道防線。將維運手冊與其他客戶的內容標示為 Restricted 後，即從組織層級禁止外部協作者存取 ，不再仰賴每一個 Space 的權限設定皆正確無誤。搭配使用者活動稽核記錄，交付後若須證明外包團隊未接觸其他內容，亦具備可查證的依據。
自動化治理
CI 流程中斷後追查發現，該組 API token 由三年前離職的同事以個人帳號建立
組織希望全面清查此類 token，但無法確認哪些 Jenkins 工作、GitHub Actions 流程或內部工具仍依賴其運作，因而遲遲未能執行停用。
兩方案的處理程度 ✓ Standard✓ Premium
✓ Guard Standard可從源頭進行治理：禁止使用者自行建立 API token、對既有 token 設定到期時間以強制輪替，並改以服務帳號（上限 250 個，可用 OAuth 2.0 或專屬 API token 驗證）承接自動化流程，使機器身分與個人帳號脫鉤。由上而下的關閉機制 ，仍無法在停用前評估各組 token 的影響範圍。
✓ Guard PremiumAPI token 使用行為追蹤可呈現每一組 token 的最近使用時間、呼叫來源與操作內容 。有了這份清單，清查工作即可從無從評估的停用風險，轉為依相依性排序的分階段遷移。
某開發小組為簡化流程，自行以公司信箱申請了一個免費 Confluence 站台存放設計文件
該站台已使用八個月，未納入單一登入、未納入備份機制，組織層級亦無人知悉其存在，而這些帳號實際上已計入每月的 Guard 帳單。
兩方案的處理程度 ✓ Standard✓ Premium
✓ Guard Standard產品探索（Product Discovery）即針對此情境設計：只要帳號使用已驗證網域，該站台便會被列出，後續可執行納管、合併或關閉。此外，這些帳號本即已計入 Guard 帳單 ，盤點未納管站台因而同時涉及資安與成本兩個面向。
✓ Guard Premium識別站台僅為第一步。完成納管後執行一次內容掃描，方能確認這八個月間累積了哪些內容。測試帳號密碼、客戶名單與尚未公開的產品規劃，常見於此類未納管的站台。
正式環境事故處理期間，工程師將資料庫查詢結果貼入事故單以利討論
該筆輸出包含四十餘位真實使用者的電子郵件與訂單內容。事故於九十分鐘後排除，事故單則保持開放，並依慣例同步至公司內的公開頻道。
兩方案的處理程度 ✓ Premium
此情境不在覆蓋範圍內。高壓情境下的貼上行為，任何以人員自律為基礎的管制都難以生效；而 Standard 並不檢視內容，事後亦無從得知該筆資料曾經存在於工單之中。
✓ Guard Premium留言於送出當下即命中電子郵件與個人資料樣式，可自動遮蔽並通知事故指揮人員。事故檢討階段，則可自稽核記錄確認該筆內容在遮蔽前的實際曝光範圍——這正是通報義務判斷所需的資訊：是否構成個資事故，取決於有多少人在何時看過 。
開發團隊導入 AI 編碼助理，以一組服務帳號授予其讀取 Jira 與 Confluence 的權限
該帳號的可見範圍實質等同於一位資深工程師，且其行為由提示詞驅動、呼叫次數頻繁。若某日出現大量而異常的讀取，組織需要能夠察覺。
兩方案的處理程度 ✓ Standard✓ Premium
✓ Guard Standard治理的起點在此：禁止使用者自行建立 API token、對既有 token 設定到期輪替，並改以服務帳號（上限 250 個，可用 OAuth 2.0 或專屬 API token 驗證）承接自動化流程與 AI 代理的存取，使機器身分與個人帳號脫鉤，其權限範圍得以單獨界定、單獨回收。
✓ Guard PremiumAPI token 使用行為追蹤可呈現該帳號的呼叫來源、頻率與操作內容，異常讀取因而具備可比較的基準線。若內容已完成分類，Restricted 等級的頁面亦可自政策層排除於代理的可見範圍之外——AI 代理與人員適用同一套規則 ，此為近期最常被詢問、實際上卻最少被設定的一環。
上述場景的共同結構： Standard 界定「何人可取得存取權」，此層若未落實，後續機制均無從發揮作用；Premium 則回應「取得存取權之後發生了什麼、組織多久後得知、以及能否完成處置」。若組織現階段的課題仍集中於第一層，優先將 Standard 落實至完整狀態；若已面臨第二層的問責要求，則須由 Premium 提供對應能力。
法規與合規
Guard 的能力對應到哪些法規與控制項
資安稽核與供應商審查最常索取的證據，不外乎四件事：誰能登入、誰看過什麼、敏感資料在哪、外洩時如何處置。Guard 的身分管控、稽核記錄、資料分級與偵測回應，可作為下列控制項的技術措施之一。須注意：本表的用途是協助準備稽核，不等於導入即合規——控制項是否達成，仍須搭配組織的程序、權責分工與紀錄一併檢視。
將游標移到或點選表中的編號，此處會顯示完整的控制項名稱。
如何使用本表： 「對應」指 Guard 可作為該控制項的技術措施之一，不代表單一功能即滿足該控制項；是否達成仍由稽核依組織整體制度判定。各欄引用的法規版本與出處見下方。
資料來源與版本
ISO ：ISO/IEC 27001:2022 Annex A。NIST ：NIST CSF 2.0（CSWP 29，2024 年 2 月）。 個資法 ：《個人資料保護法施行細則》（105 年 3 月修正）第 12 條第 2 項。母法原為個資法第 27 條第 1 項，114 年 11 月修正後移列第 20-1 條，施行日期由行政院另定。 金管會 ：「方案 2.0」為《金融資安行動方案 2.0》（111 年 12 月）；「基準」為銀行公會《金融機構資通安全防護基準》（114 年 2 月備查版）；「安維」為《金管會指定非公務機關個人資料檔案安全維護辦法》（110 年 12 月修正）；「委外」為《金融機構作業委託他人處理內部作業制度及程序辦法》（115 年 4 月修正）。非銀行業者請對照各業別公會規範。 Guard 驗證報告 ：SOC 2、ISO 27001 報告與《Atlassian Guard: Trust FAQ》見 Atlassian Trust Center 與 Trust Portal 。
典型採用路徑
三種起點，同一項基礎
組織的資安成熟度不同，導入 Guard 的時機亦有差異。Guard Standard 為各條路徑共同的起點，差異在於後續的發展方向。
基礎
Atlassian Guard Standard
Standard 為在 Atlassian Cloud 維持安全協作的基準層，涵蓋強制單一登入、集中稽核與自動化佈建。此層未完備時，後續的分級與偵測機制缺乏可靠的基礎。
先行導入 Cloud Enterprise
重視擴展性、合規與分析能力，需求已超出單純的資安控制範疇，例如自帶金鑰與多站台治理。此類組織後續多半會再疊加 Guard Premium，以取得偵測與回應能力。
先行升級 Guard Premium
認同保護、偵測、回應的完整循環，優先需求為資料分級、內容掃描與事件回應。待組織規模成長後，再導入 Cloud Enterprise 以補足分析與擴展性需求。
僅採用 Guard Premium
對擴展性與分析的需求相對有限，關注重點集中於更深入的資安洞察與控制。常見於資安團隊主導採購、且整體站台規模尚未達到 Enterprise 門檻的組織。
定價與計費
依不重複使用者計價，不因產品或站台數量重複收費
同一位使用者無論持有多少站台或產品的存取權，在 Guard 帳單中僅計算一次。使用者人數愈多，單價級距愈低；年繳約可節省 17%，相當於兩個月的費用。
Guard Standard
US$ 4.20
每位使用者／月 起（月繳，依人數級距遞減）
已內含於 Cloud Enterprise，以及 Teamwork Collection 的 Premium 與 Enterprise 方案
1 至 10 人適用月繳定額 US$30
免費版 Jira、Confluence、Trello 的帳號亦計入
JSM（Jira Service Management）客戶入口（portal-only）帳號不計費
Guard Premium
US$ 8.18
每位使用者／月 起（月繳，依人數級距遞減）
已持有 Cloud Enterprise、Teamwork Collection Premium／Enterprise 或 Guard Standard 者，僅需補足價差
依 Jira 與 Confluence 的存取人數計算
列入非計費政策的帳號，仍計入 Premium 計費
受管帳號與外部使用者均納入計費
關於價格差異的說明： Atlassian 產品頁目前標示 Standard 為每人每月 US$4.20 起、Premium 為 US$8.18 起，而授權常見問題的月繳級距表中，11 至 250 人區間為 US$4.00。兩處數據並不一致，實際金額請以官方定價計算工具與正式報價為準。年繳採級距總價制，須另行取得報價。
導入路線圖
從決定到上線：六個步驟與各自的風險點
Standard 的導入核心是兩件事：把散落的帳號收進組織成為 Managed accounts，交給公司的 IdP；Premium 的分級與政策皆建立在這個基礎上。順序不宜對調，因為後一步依賴前一步產出的資料——資料安全政策需要已分級的內容。
Step 0
前置盤點
列出組織內所有 Atlassian Cloud 站台（含同仁自行申請的免費站台）、公司持有的全部 email 網域、現行 IdP（Entra ID／Okta／Google Workspace），以及既有的 Marketplace 應用程式與 API 整合。
前置條件 Org admin 權限。
風險與避免方式 漏列網域會造成部分帳號無法納管；子公司、舊品牌與併購而來的網域尤其容易遺漏，盤點時一併列入。
Step 1
網域驗證與帳號認領
以 DNS TXT 記錄或 HTTPS 檔案驗證網域所有權，再認領（claim）使用該網域的帳號，使其成為 Managed accounts。
前置條件 可修改 DNS 記錄；步驟 0 的網域清單已確認。
風險與避免方式 認領後，帳號的顯示名稱與密碼原則改由組織管控，個人自行申請的帳號也會一併納入；務必事先溝通，並說明既有內容與權限不受影響。
Step 2
SSO 與驗證政策
在 Admin Hub 以 SAML 或 OIDC 串接 IdP；先建立一組僅含 IT 團隊帳號的測試用 Authentication policy，確認登入無誤後，再將設定套用到預設政策。
前置條件 IdP 管理權限；步驟 1 已完成。
風險與避免方式 直接對預設政策強制 SSO，IdP 設定一有錯誤即全員鎖帳。務必保留一個不走 SSO 的緊急管理帳號，放在獨立的 Authentication policy 中。
Step 3
SCIM 佈建與群組對應
由 IdP 推送使用者與群組至 Atlassian，將群組對應到各產品的存取權；人員於 IdP 停用後，Atlassian 的存取權隨即自動撤銷。
前置條件 步驟 2 已完成；IdP 的群組結構已整理。
風險與避免方式 SCIM 推送的群組與既有手動建立的群組同名會發生衝突，導致佈建失敗或權限錯置；先清理或改名，再開啟同步。
Step 4
API token、行動裝置 與外部使用者政策
限制使用者自建 API token 或設定到期時間、設定 Mobile app policy，並對非受管的外部協作者套用 External user security（例如強制兩步驟驗證）。
前置條件 步驟 1 已完成（政策以受管帳號為對象）。
風險與避免方式 既有 CI／整合若以個人 API token 運作，token 到期或被禁止後即告中斷；先盤點所有整合，改由 service account 持有 token。
Step 5
Premium：分級、政策、偵測、SIEM
先以內容掃描盤點既有的敏感內容，再設定分類等級與自動分類規則，接著建立資料安全政策，最後調整偵測規則並以 webhook 接入 SIEM。
前置條件 Guard Premium 訂閱；步驟 1–3 已完成。
風險與避免方式 政策一開就對整個產品套用「禁止匯出」會直接影響日常工作。先從 Restricted 等級與少數空間開始，確認無誤後再逐步擴大。
導入檢查清單（前置作業・切換當週・上線後）
前置作業
已列出所有 *.atlassian.net 站台，以及組織的 Org admin 與各站台的 site admin
已列出公司持有的全部 email 網域，含子公司與舊品牌網域
已確認 DNS 管理者與 IdP 管理者，並排定變更時窗
已盤點所有使用個人 API token 的 CI／整合，並規劃改用 service account
已建立不走 SSO 的緊急管理帳號，並記錄於密碼保險箱
已在 IdP 建立僅含 IT 團隊的測試群組，供測試用 Authentication policy 使用
切換當週
已通知使用者切換日期與登入方式變化，並提供 FAQ 與支援窗口
已於測試政策完成 SSO 登入、登出與 session 逾時後重新登入的驗證
已確認 IdP 群組與 Atlassian 既有群組沒有同名衝突
已將預設 Authentication policy 切換為強制 SSO，並確認緊急管理帳號仍可登入
已開啟 SCIM 同步，並核對首批佈建的使用者與群組數量
已匯出切換前的使用者與群組清單，供回溯比對
上線後
已驗證離職流程：IdP 停用後依同步週期撤銷存取（Entra ID 預設約 40 分鐘），既有 session 依驗證政策的 session duration 失效
已驗證到職流程：加入 IdP 群組後自動取得對應產品的存取權
已檢視組織稽核記錄，確認驗證政策變更與使用者存取異動正常記錄（登入失敗需查 IdP 端記錄）
已設定 API token 到期政策，並排定既有 token 的輪替時間
已排定每季檢視：未受管帳號、外部使用者與閒置帳號
（Premium）已確認告警送達 SIEM，並指定告警的處理負責人
關於本路線圖： 各步所需時間依組織規模、站台數量與 IdP 現況差異很大，建議在盤點後再估。上述任一步驟均可由 Titansoft 顧問協助規劃與執行，歡迎預約 Demo 。
產品沿革
從 Atlassian Access 到 Atlassian Guard
Atlassian 於 2024 年將 Access（2018 年推出的身分與存取管理）與 Beacon（2023 年進入 Beta 的威脅偵測）合併，並新增資料外洩防護，整合為 Guard。原 Atlassian Access 的訂閱者即為現行的 Guard Standard ；Beacon 的能力則併入 Guard Premium。
2011 Jira 與 Confluence Cloud Atlassian 雲端產品線的起點 2018 Atlassian Access 推出 首個專為 Atlassian Cloud 設計的身分與存取管理工具 2023 Beacon 進入 Beta 威脅偵測與回應能力 2024 Atlassian Guard 發表 整合 Access 與 Beacon，並新增資料外洩防護
常見問題
導入前最常被提出的問題
導入與功能範圍
導入 Guard 之前需要完成哪些前置作業？
Guard Standard 有兩項前置作業：網域驗證（domain verification）與使用者認領（user claim）。組織須先證明擁有該電子郵件網域，方能將使用該網域的 Atlassian 帳號納為受管帳號，後續的單一登入、驗證政策與稽核機制才會生效。此步驟需與 IT 或 DNS 管理者協調，其所需時間會影響整體導入時程。完整的六步順序與各步風險點，見導入路線圖 。
哪些訂閱已內含 Guard Standard？
Cloud Enterprise 訂閱內含 Guard Standard。此外，Teamwork Collection 的 Premium 與 Enterprise 方案亦內含 Guard Standard，Standard 方案則不包含。已透過上述任一訂閱取得 Guard Standard 的組織，若後續要升級 Guard Premium，僅需補足每位使用者的價差，無須重複購買 Standard。
免費版的使用者是否也會計入費用？
會。只要帳號位於受 Guard 管理的網域，並持有 Jira、JSM、Confluence、Bitbucket、Trello 或 Statuspage（含免費版）的存取權，即計入 Guard Standard 帳單。若確認部分帳號無須納管，可建立非計費政策將其排除。惟須留意，這些帳號同時也不再受 Standard 的功能保護，且在 Premium 的計費中仍會被計入。
Premium 為何僅支援 Jira 與 Confluence？
Premium 的核心能力為內容掃描與資料分級，目前的偵測引擎涵蓋 Jira 與 Confluence Cloud。Bitbucket、Trello 與 Statuspage 仍在 Standard 的身分與存取控制範圍內，但不受內容掃描涵蓋。若組織的敏感資料主要存放於程式碼儲存庫，須另行評估補強方案。
資料外洩防護的偵測範圍有哪些已知限制？
內容掃描目前針對頁面與議題的文字內容，有三項已知的涵蓋限制：不執行光學文字辨識、不涵蓋附件檔案內容，且尚未支援 Confluence Whiteboard。以掃描檔或附件形式流通敏感資料的組織，實際覆蓋率會低於偵測項目數所呈現的水準，此差距須於概念驗證階段實測確認。
取消訂閱後會產生哪些影響？
強制單一登入與強制兩步驟驗證將失效，使用者改以 Atlassian 帳號登入，部分人員可能需重設密碼；內容掃描與行為偵測停止運作，告警不再送出。已驗證的網域不受影響，仍可繼續檢視與管理受管帳號，部分關鍵設定會保留一段期間。退款僅限月繳試用後的第一個付費月份內，或年繳付款後 30 日內提出。
是否可以先行試用？
可以。兩種方案均提供 30 天免費試用，由組織管理員於 admin.atlassian.com 啟用。試用期間可選定兩至三個代表性的 Space 或專案執行全站掃描，以實際命中結果驗證偵測規則與組織資料型態的符合程度。
使用者與計費
受管使用者、計費使用者與外部使用者如何區分？
受管使用者（managed users）指帳號位於已驗證網域、因而受組織控管的帳號；計費使用者（billable users）則是實際計入帳單的人數。兩者不必然相等：受管帳號若未持有任何受支援產品的存取權，就不會計費；反之，非受管網域的外部協作者只要具備受支援產品的存取權，仍會計入 Standard 帳單。實際人數可於 admin.atlassian.com 的帳單預估頁面查看。報價應以該數字為準；以組織通訊錄人數推估通常與實際計費人數有落差。
Premium 的計費人數如何認定？與 Standard 有何不同？
兩者的計費基礎並不相同。Standard 計入具備 Jira、JSM（Agent）、Confluence、Bitbucket、Trello 或 Statuspage 存取權的使用者；Premium 則僅計入具備 Jira 或 Confluence 存取權者，且不分方案版本。已停用的帳號、未持有任何產品存取權者，以及僅使用 JSM 或 Jira Product Discovery 的使用者，不計入 Premium。因此在同一組織中，Premium 的計費人數通常低於 Standard，估算升級成本時，直接以 Standard 的人數乘以價差會高估實際金額。
JSM 的報修者會計入費用嗎？
不會。僅透過客戶入口網站（portal-only）提交或追蹤案件的帳號，不計入 Guard Standard 帳單；實際處理案件的 JSM Agent 才會計費，且該 Agent 須使用受管帳號。對於以 JSM 作為全公司 IT 服務台、報修者動輒數百至數千人的組織，此項差異對總成本的影響幅度大，估算時須區分 Agent 與報修者的人數。
人數成長時帳單會如何變動？會事先通知嗎？
Guard 依當期實際計費人數計算，人數增加時帳單隨之提高。若當期金額高於前一期，帳務與技術聯絡人會在扣款前三日收到通知信；但這是扣款前的告知，而非事前核准機制。人數波動較大的組織可於 admin.atlassian.com 的訂閱管理頁面定期檢視使用量。將「新進人員取得產品存取權」納入既有的帳號開通流程，可避免帳單在未經察覺的情況下逐月增加。
延伸閱讀
從概念到導入現場：三篇可延伸閱讀的實作文章
由 Titansoft 顧問團隊撰寫、發表於 Medium，依「是什麼、帳號怎麼管、事件怎麼處理」的順序由淺入深。
