Atlassian Guard · Standard 與 Premium 選版指南
Atlassian Guard 是套用於整個 Atlassian Cloud 組織的資安附加訂閱，將身分驗證、資料分級、敏感內容偵測與事件回應整合於單一管理平面。其目的並非新增一套獨立的資安工具，而是讓 Jira 與 Confluence 中實際流動的資料，具備可被治理與稽核的基礎。
LEVEL 1
可對外公開，允許匿名檢視與公開分享連結。
LEVEL 2
限組織內部檢視，封鎖對外分享連結。
LEVEL 3
偵測到信用卡號等敏感樣式時自動升級標籤，並禁止匯出。
LEVEL 4
禁止外部協作者存取，命中時觸發告警與建議修復動作。
導入背景
多數組織已在端點防護、雲端存取安全代理與資安事件管理平台上投入相當資源，但 Jira 議題附件與 Confluence 頁面中的合約條款、客戶名單與系統憑證，通常未被納入同一套治理框架。實務上的風險缺口多半並非外部入侵，而是三類日常性疏漏：離職人員的存取權未即時解除、內部頁面被設定為公開連結、以及 AI 助理檢索到原本不應納入索引的內容。
Atlassian Guard 針對的正是這一段落差。Standard 建立身分與存取的邊界，Premium 則延伸至資料本身：內容於寫入當下即完成掃描與分級，異常行為在數分鐘內轉為告警，並提供可直接執行的修復建議。
三大價值支柱
Guard 依循「保護、偵測、回應」的完整循環設計。Standard 涵蓋前段的存取控制與可視性，Premium 補齊資料層的偵測能力與事件回應機制。
透過彈性的政策設定，界定哪些人員、在何種裝置條件下，可對特定等級的資料執行哪些操作。
將風險盤查從人工抽查，轉為持續性掃描與規則化偵測。
告警必須能銜接既有的資安作業流程，而非形成另一個無人處理的通知管道。
完整功能對照
Premium 為疊加於 Standard 之上的方案，並非替代選項。Guard Standard 已內含於 Cloud Enterprise，以及 Teamwork Collection 的 Premium 與 Enterprise 方案；上述訂閱的持有者在升級 Premium 時，僅需補足每位使用者的價差。
| 功能 | StandardUS$4.20 / 人 / 月起 | PremiumUS$8.18 / 人 / 月起 |
|---|---|---|
| 身分與存取管理 | ||
| 強制單一登入支援 SAML 與 OIDC，可串接 Okta、Microsoft Entra ID、Google Workspace | ✓ | ✓ |
| 強制兩步驟驗證 | ✓ | ✓ |
| 多組驗證政策最多 20 組，可分別套用於不同使用者群體，並支援小範圍先行驗證 | ✓ | ✓ |
| 非計費政策將無須納管的帳號排除於 Standard 計費之外 | ✓ | ✓ |
| 外部使用者政策針對非受管網域的協作者套用獨立安全設定 | ✓ | ✓ |
| SCIM 自動化使用者佈建與解除佈建 | ✓ | ✓ |
| 使用者 API token 管控與到期設定 | ✓ | ✓ |
| 行動應用程式管理限制截圖、螢幕錄影與檔案下載 | ✓ | ✓ |
| 密碼原則、閒置逾時、工作階段與行動應用逾時 | ✓ | ✓ |
| OAuth 2.0 服務帳號上限 | 250 | 1,000 |
| 資料保護 Protect | ||
| 資料安全政策限制匯出、公開連結、匿名存取與第三方應用程式存取 | ✓ | ✓ |
| 組織層級資料分類標籤Public、Internal、Confidential、Restricted 四級 | ✓ | |
| 自動分類偵測到信用卡號等敏感樣式時自動套用對應標籤 | ✓ | |
| 以分類等級為條件的組織級政策 | ✓ | |
| 偵測 Detect | ||
| 組織洞察活躍使用者統計與驗證方式分布 | ✓ | ✓ |
| 產品探索識別組織內未納管的 Atlassian 站台 | ✓ | ✓ |
| 管理員活動稽核記錄 | ✓ | ✓ |
| 使用者活動稽核記錄（延伸稽核） | ✓ | |
| API token 使用行為追蹤 | ✓ | |
| 可疑活動偵測與告警涵蓋異常登入、大量匯出與資料外洩徵兆 | ✓ | |
| 內容掃描60 項以上內建偵測，涵蓋個人資料、金融資訊、憑證與健康資料 | ✓ | |
| 自訂偵測規則依組織自有的資料樣式建立 | ✓ | |
| 全站掃描與即時掃描既有內容一次性盤點，新增內容於寫入當下判定 | ✓ | |
| 回應 Respond | ||
| 統一告警檢視與調查儀表板包含行為者脈絡與事件時間軸 | ✓ | |
| 稽核記錄串流至資安事件管理平台透過 Webhook 與 API，可串接 Splunk 等平台 | ✓ | |
| Slack 與 Microsoft Teams 告警通知 | ✓ | |
| 建議修復動作停用帳號、遮蔽敏感內容、重新分類 | ✓ | |
| AI 治理 | ||
| Rovo Chat 提示與回應內容掃描阻擋或遮蔽出現於 AI 對話中的敏感資料 | ✓EA | |
| 連接器資料安全避免第三方來源的敏感資料被納入 Teamwork Graph | ✓EA | |
| 涵蓋範圍與計費 | ||
| 支援的雲端產品 |
|
|
| 是否已內含於其他訂閱已內含 Standard 者，升級 Premium 時僅需補足每位使用者的價差 | ✓
| 另行購買，補足價差 |
選版的判斷基準：若組織目前的核心課題在於「帳號如何取得存取權、如何解除存取權」，Standard 已可滿足需求。若需回應的是「內容中存在哪些不應存在的資料、由何人於何時存取、能否於短時間內完成處置」，則僅有 Premium 具備對應能力。後者通常也是金融、醫療與其他受監管產業在稽核程序中被要求說明的項目。
重點能力說明
功能對照表以單行呈現各項能力，但其中數項的實際運作方式會直接影響導入工作量與選版判斷。以下就最容易被低估的六項補充說明。
Guard Premium 於組織層級提供 Public、Internal、Confidential、Restricted 四級標籤，套用對象為 Confluence 頁面與 Jira 議題。須留意標籤本身不具強制力：將頁面標為 Restricted 不會自動封鎖任何操作，必須另行建立「以分類等級為條件的組織級政策」，該等級才會實際限制分享與匯出行為。
自動分類則於內容寫入時比對敏感樣式，命中信用卡號等格式即自動套用對應等級，用以降低仰賴人工標記所產生的落差。實務上建議先以手動分級為少量高價值內容建立基準，再逐步開啟自動分類；初期若出現大量誤判，使用者會很快對標籤失去信任。
可限制匯出、公開分享連結、匿名存取與第三方應用程式的資料存取，兩種方案均具備。差別在於套用條件：Standard 以空間或專案為範圍，屬一體適用；Premium 則可將分類等級作為條件，例如「Confidential 以上一律封鎖對外分享連結，Internal 以下不受限」。
這往往是評估是否升級的關鍵分野。若安全要求可以用「整個空間全開或全關」表達，Standard 已足夠；若必須依內容本身的敏感程度採取不同管制，才需要 Premium 的分級能力。
內容掃描提供 60 項以上內建偵測，涵蓋個人資料、金融資訊、憑證與健康資料，並以兩種模式運作：全站掃描對既有內容執行一次性盤點，即時掃描則於內容寫入當下判定。
內建偵測以國際通用格式為主（信用卡號、雲端服務金鑰、美國社會安全號碼等）。台灣的身分證字號、健保卡號與統一編號不在預設清單內，須以自訂偵測規則建立。評估階段應將此工作量納入導入時程，並以組織既有內容實測命中率——掃描目前不執行光學文字辨識、亦不涵蓋附件內容，對以掃描檔流通文件的組織影響甚大。
兩者的差別可以一句話概括：Standard 能回答「管理員做了什麼」，Premium 才能回答「使用者對資料做了什麼」。
Standard 提供管理員活動稽核記錄、組織洞察（活躍使用者統計與驗證方式分布），以及產品探索（識別組織內未納管的 Atlassian 站台）。Premium 另加使用者活動稽核（延伸稽核）與 API token 使用行為追蹤。離職人員的存取歷程盤查，或稽核單位要求說明「何人於何時檢視過哪份文件」這類需求，僅憑 Standard 的管理員記錄無法完成。
可疑活動偵測涵蓋異常登入、大量匯出與資料外洩徵兆，命中後於統一的調查儀表板呈現，包含行為者脈絡與事件時間軸，免去跨多個管理介面拼湊事件經過。告警可送達 Slack 或 Microsoft Teams，稽核記錄亦可經 Webhook 與 API 串流至 Splunk 等資安事件管理平台。儀表板並提供可直接執行的修復動作：停用帳號、遮蔽敏感內容、重新分類。
導入時的關鍵不在偵測規則的數量，而在於告警的收斂。應於上線前即設定告警等級與接收對象，並確認高風險項目具備明確的處理時限，否則未處理告警會快速累積至無法判讀的程度。
兩項能力目前均屬 Early Access：Rovo Chat 的提示與回應內容掃描，可阻擋或遮蔽出現於 AI 對話中的敏感資料；連接器資料安全則避免第三方來源的敏感資料被納入 Teamwork Graph 的索引範圍。
Early Access 表示功能尚未正式發布，可用性、涵蓋範圍與服務水準均可能調整。若組織尚未導入 Rovo，這兩項不宜構成升級 Premium 的決定性理由；若已導入或即將導入，則建議於試用期間實際驗證，並將其視為後續強化項目，而非既有保障。
場景對照
功能清單難以呈現的差異，往往在事件發生的當下才會顯現。以下十個場景均為實務上反覆出現的類型，前五個為跨產業通用情境，後五個聚焦於軟體開發與產品公司。差異的關鍵不在於「是否防範得住」，而在於事後能否完整說明事件經過，以及從發現到處置所需的時間。
通用場景
該員於最後兩週仍持有 Confluence 技術規格庫的完整存取權。人資已於身分識別提供者停用帳號，但主管需要釐清的是：離職前該段期間內，其實際匯出與下載了哪些內容。
SCIM 會在身分識別提供者停用帳號的同時解除 Atlassian 存取權，此環節可完整覆蓋。惟稽核記錄僅涵蓋管理員操作，可查得權限設定的變更歷程，但無法回溯特定使用者的檢視與匯出行為。實務上僅能依靠頁面版本紀錄逐頁比對，而匯出行為本身並未留存記錄。
使用者活動稽核記錄會保留該員的檢視與匯出行為，可直接匯出完整時間軸供調查使用。若事前已配置大量匯出的偵測規則，此行為在離職前即會觸發告警，而非於事後才展開追查。
其原意是分享給外部設計協力廠商，因而選擇了「知道連結的人皆可檢視」。三週後，業務單位在客戶端看到了這份定價資料。
資料安全政策可於站台層級全面禁止公開連結，但此設定為全有全無：一旦啟用，行銷本應對外公開的活動說明與產品文件亦同時受限。實務上多半會因業務單位反映而重新開放，導致政策難以長期維持。
改以分類等級作為管控條件：標示為 Public 的行銷素材維持正常分享，Confidential 以上則一律禁止公開連結與匯出。定價資料因命中偵測規則而自動升級分類，該同仁在執行分享操作的當下即被阻擋，而非於三週後才由業務單位回報。
依內部規範不應存在，但組織共有 40 個 Space、累積六年的內容，且客服團隊過去確有將個案截圖與資料貼入頁面的作業習慣。此項目須於兩週內提出書面答覆。
不具備內容層的盤查能力，僅能透過 Confluence 搜尋配合人工抽查。此種作法在稽核程序中難以構成充分證據，能夠證明的是「已進行查找」，而非「已完成全面掃描」。
可運用內建的個人資料偵測，搭配自訂規則（例如台灣身分證字號格式），執行一次全站掃描並產出命中清單與所在頁面，後續可套用遮蔽或重新分類的修復動作。新增內容則於寫入當下即完成判定。
惟須先確認覆蓋範圍：掃描不含光學文字辨識、不涵蓋附件內容，亦不支援 Confluence Whiteboard。若前述截圖為影像格式，本輪掃描無法涵蓋。
該員工的密碼曾於其他網站的外洩名單中出現，且在多處重複使用。攻擊者取得的是一組合法憑證，其行為在驗證層面完全合規。
強制單一登入（Single Sign-On）與兩步驟驗證（Two-Step Verification）可大幅降低此類攻擊的成功率，為最具效益的第一道防線。惟若攻擊者已突破兩步驟驗證，Standard 不會產生任何告警，事件通常需數日後才會被察覺。
可疑活動偵測可辨識異常登入與大量下載的組合行為，於數分鐘內將告警送至 Microsoft Teams、Slack 或資安事件管理平台。告警本身即附帶行為者脈絡與事件時間軸，並提供停用帳號的建議動作，資安人員可於同一介面完成處置。
資料來源為人資兩年前建立的一頁 Confluence，當初的權限設定開放給全公司，後續無人重新檢視。AI 並未執行任何違規操作，僅是呈現了原本即處於開放狀態的內容。
AI 的可見範圍等同於既有的頁面權限，而權限的設定偏差多為長期累積的結果。Standard 不具備盤點「哪些高敏感內容的權限範圍過寬」的能力，此類問題通常須待實際被查詢後才會浮現。
內容掃描可在 AI 導入前先行盤點出此類頁面並標示為 Restricted，分類標籤本身亦會被 AI 讀取，成為可見範圍的判斷依據。另提供 Rovo Chat 的提示與回應掃描（Early Access），可於對話層阻擋或遮蔽敏感內容。
軟體開發／產品公司場景
該議題共有 12 位關注者，其中兩位為外部協力廠商。問題排除後未有人回頭清除該則留言，內容持續留存於議題中。
此情境不在 Standard 的能力範圍內。Standard 管理的是存取層，不檢視議題的內容本身。此類憑證通常須待實際遭到濫用，或於下一次資安健檢的人工抽查中才會被發現。
內建偵測涵蓋憑證與金鑰類樣式，留言於寫入當下即會命中並觸發告警，可直接套用遮蔽的修復動作。
惟涵蓋範圍須予釐清：內容掃描僅支援 Jira 與 Confluence，不包含 Bitbucket。程式碼中的硬編碼憑證仍須由專用的 secret scanning 機制處理。
其存取範圍應僅限於該專案，但 Confluence 中同時存有其他客戶的規格文件、內部架構圖，以及一份載明各環境連線方式的維運手冊。
此層級的需求 Standard 已可有效覆蓋：外部使用者政策允許對這 20 人套用獨立規則，包括強制兩步驟驗證、縮短工作階段逾時、禁止建立 API token，以及在行動裝置上限制下載與截圖。專案結束時可透過 SCIM 一次性完成權限回收。
Premium 補強的是 Space 權限設定發生疏漏時的第二道防線。將維運手冊與其他客戶的內容標示為 Restricted 後，即從組織層級禁止外部協作者存取，不再仰賴每一個 Space 的權限設定皆正確無誤。搭配使用者活動稽核記錄，交付後若須證明外包團隊未接觸其他內容，亦具備可查證的依據。
組織希望全面清查此類 token，但無法確認哪些 Jenkins 工作、GitHub Actions 流程或內部工具仍依賴其運作，因而遲遲未能執行停用。
可從源頭進行治理：禁止使用者自行建立 API token、對既有 token 設定到期時間以強制輪替，並改以 OAuth 2.0 服務帳號（上限 250 個）承接自動化流程，使機器身分與個人帳號脫鉤。
惟此為由上而下的關閉機制，仍無法在停用前評估各組 token 的影響範圍。
API token 使用行為追蹤可呈現每一組 token 的最近使用時間、呼叫來源與操作內容。有了這份清單，清查工作即可從無從評估的停用風險，轉為依相依性排序的分階段遷移。
組織與雙方均簽有保密協議。此行為本身可能僅是一次文件整理，但若客戶 A 提出查詢，組織必須能明確說明何人於何時檢視過該文件。
Space 權限設計再嚴謹，仍無法防範內容被主動移至權限範圍較寬的位置。事後追查時，Standard 的稽核記錄僅涵蓋管理員操作，無法回應「哪些人員檢視過該頁面」。
分類標籤依附於內容本身而非所在的 Space，標示為 Restricted 的規格文件無論移至何處，均受同一套政策約束。若事件確實發生，使用者活動稽核記錄可列出完整檢視紀錄，此為對客戶說明時能否完成結案的關鍵差異。
該站台已使用八個月，未納入單一登入、未納入備份機制，組織層級亦無人知悉其存在，而這些帳號實際上已計入每月的 Guard 帳單。
產品探索（Product Discovery）即針對此情境設計：只要帳號使用已驗證網域，該站台便會被列出，後續可執行納管、合併或關閉。此外，這些帳號本即已計入 Guard 帳單，因此盤點影子 IT 通常同時具備資安與成本管控的效益。
識別站台僅為第一步。完成納管後執行一次內容掃描，方能確認這八個月間累積了哪些內容。測試帳號密碼、客戶名單與尚未公開的產品規劃，多半出現在此類未納管的站台之中。
上述場景的共同結構：Standard 界定「何人可取得存取權」，此層若未落實，後續機制均無從發揮作用；Premium 則回應「取得存取權之後發生了什麼、組織多久後得知、以及能否完成處置」。若組織現階段的課題仍集中於第一層，優先將 Standard 落實至完整狀態較具效益；若已面臨第二層的問責要求，Premium 便不屬於加值選項，而是唯一可行的方案。
典型採用路徑
組織的資安成熟度不同，導入 Guard 的時機亦有差異。但無論由何種需求切入，Guard Standard 均為維持安全協作的共同基準，差異在於後續的發展方向。
所有企業級組織均應將 Standard 視為在 Atlassian Cloud 維持安全協作的必要條件，涵蓋強制單一登入、集中稽核與自動化佈建。此層若未完備，後續的分級與偵測機制皆缺乏可靠的基礎。
重視擴展性、合規與分析能力，需求已超出單純的資安控制範疇，例如自帶金鑰與多站台治理。此類組織後續多半會再疊加 Guard Premium，以取得偵測與回應能力。
認同保護、偵測、回應的完整循環，優先需求為資料分級、內容掃描與事件回應。待組織規模成長後，再導入 Cloud Enterprise 以補足分析與擴展性需求。
對擴展性與分析的需求相對有限，關注重點集中於更深入的資安洞察與控制。常見於資安團隊主導採購、且整體站台規模尚未達到 Enterprise 門檻的組織。
定價與計費
同一位使用者無論持有多少站台或產品的存取權，在 Guard 帳單中僅計算一次。使用者人數愈多，單價級距愈低；年繳約可節省 17%，相當於兩個月的費用。
| Guard Standard 月繳級距 | 每位使用者單價 |
|---|---|
| 1 – 10 人 | US$30 定額 |
| 11 – 250 人 | US$4.00 |
| 251 – 1,000 人 | US$3.20 |
| 1,001 – 5,000 人 | US$1.80 |
| 5,001 人以上 | US$1.20 |
關於價格差異的說明：Atlassian 產品頁目前標示 Standard 為每人每月 US$4.20 起、Premium 為 US$8.18 起，而授權常見問題的月繳級距表中，11 至 250 人區間為 US$4.00。兩處數據並不一致，實際金額請以官方定價計算工具與正式報價為準。年繳採級距總價制，須另行取得報價。
常見問題
Guard Standard 有兩項前置作業：網域驗證（domain verification）與使用者認領（user claim）。組織須先證明擁有該電子郵件網域，方能將使用該網域的 Atlassian 帳號納為受管帳號，後續的單一登入、驗證政策與稽核機制才會生效。此步驟通常需與 IT 或 DNS 管理者協調，建議預留充分時程。
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 Cloud。Bitbucket、Trello 與 Statuspage 仍在 Standard 的身分與存取控制範圍內，但不受內容掃描涵蓋。若組織的敏感資料主要存放於程式碼儲存庫，須另行評估補強方案。
內容掃描目前針對頁面與議題的文字內容。實務評估時應特別確認幾項常見盲點：不執行光學文字辨識、不涵蓋附件檔案內容，且尚未支援 Confluence Whiteboard。若組織的敏感資料多以掃描檔或附件形式流通，將直接影響覆蓋率評估，建議於概念驗證階段即進行實測。
強制單一登入與強制兩步驟驗證將失效，使用者改以 Atlassian 帳號登入，部分人員可能需重設密碼；內容掃描與行為偵測停止運作，告警不再送出。已驗證的網域不受影響，仍可繼續檢視與管理受管帳號，部分關鍵設定會保留一段期間。退款僅限月繳試用後的第一個付費月份內，或年繳付款後 30 日內提出。
可以。兩種方案均提供 30 天免費試用，由組織管理員於 admin.atlassian.com 啟用。建議於試用期間即選定兩至三個最具代表性的 Space 或專案執行全站掃描，以實際命中結果驗證偵測規則是否符合組織的資料型態，而非僅就功能清單進行評估。
受管使用者（managed users）指帳號位於已驗證網域、因而受組織控管的帳號；計費使用者（billable users）則是實際計入帳單的人數。兩者不必然相等：受管帳號若未持有任何受支援產品的存取權，就不會計費；反之，非受管網域的外部協作者只要具備受支援產品的存取權，仍會計入 Standard 帳單。實際人數可於 admin.atlassian.com 的帳單預估頁面查看，建議報價前以該數字為準，而非以組織通訊錄的人數推估。
兩者的計費基礎並不相同。Standard 計入具備 Jira、JSM（Agent）、Confluence、Bitbucket、Trello 或 Statuspage 存取權的使用者；Premium 則僅計入具備 Jira 或 Confluence 存取權者，且不分方案版本。已停用的帳號、未持有任何產品存取權者，以及僅使用 JSM 或 Jira Product Discovery 的使用者，不計入 Premium。因此在同一組織中，Premium 的計費人數通常低於 Standard，估算升級成本時不應直接以 Standard 的人數乘以價差。
不會。僅透過客戶入口網站（portal-only）提交或追蹤案件的帳號，不計入 Guard Standard 帳單；實際處理案件的 JSM Agent 才會計費，且該 Agent 須使用受管帳號。對於以 JSM 作為全公司 IT 服務台、報修者動輒數百至數千人的組織，此項差異對總成本的影響甚大，評估時應明確區分 Agent 與報修者的人數。
Guard 依當期實際計費人數計算，人數增加時帳單隨之提高。若當期金額高於前一期，帳務與技術聯絡人會在扣款前三日收到通知信；但這是扣款前的告知，而非事前核准機制。對人數波動較大的組織，建議定期於 admin.atlassian.com 的訂閱管理頁面檢視使用量，並將「新進人員取得產品存取權」納入既有的帳號開通流程，避免帳單在無人察覺的情況下逐月墊高。