<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>授權 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E6%8E%88%E6%AC%8A/</link><description>Recent content in 授權 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 23 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E6%8E%88%E6%AC%8A/index.xml" rel="self" type="application/rss+xml"/><item><title>Authorization</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/authorization/</link><pubDate>Thu, 23 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/authorization/</guid><description>&lt;p>Authorization 的核心概念是「判斷已識別主體是否能執行某個操作」。&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/authentication/" data-link-title="Authentication" data-link-desc="說明系統如何確認呼叫者身份">Authentication&lt;/a> 回答你是誰；authorization 回答你能做什麼、對哪個資源做、在什麼條件下做。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Authorization 是資料保護與操作安全的核心邊界。它可以用 role、permission、policy、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/tenant-boundary/" data-link-title="Tenant Boundary" data-link-desc="說明多租戶系統如何隔離不同客戶或組織的資料與資源">tenant boundary&lt;/a>、resource owner 或 attribute-based rule 表達。&lt;/p>
&lt;h2 id="可觀察訊號與例子">可觀察訊號與例子&lt;/h2>
&lt;p>系統需要授權模型的訊號是角色、資料範圍或操作風險開始分級。客服可以查看訂單狀態，但調整退款、下載 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/pii/" data-link-title="PII" data-link-desc="說明可識別個人的資料如何影響權限、遮罩、保留與稽核">PII&lt;/a> 或修改權限應需要更高權限與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/audit-log/" data-link-title="Audit Log" data-link-desc="說明高風險操作如何留下可追溯、可稽核的紀錄">audit log&lt;/a>。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>授權設計要定義主體、資源、操作、條件、拒絕原因與稽核欄位。測試要覆蓋跨 tenant 存取、低權限升級、高風險操作、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/function-level-authorization/" data-link-title="Function-Level Authorization" data-link-desc="說明功能操作本身也需要授權，不只資源 ID 需要授權">function-level authorization&lt;/a> 與資料匯出。&lt;/p></description><content:encoded><![CDATA[<p>Authorization 的核心概念是「判斷已識別主體是否能執行某個操作」。<a href="/blog/backend/knowledge-cards/authentication/" data-link-title="Authentication" data-link-desc="說明系統如何確認呼叫者身份">Authentication</a> 回答你是誰；authorization 回答你能做什麼、對哪個資源做、在什麼條件下做。</p>
<h2 id="概念位置">概念位置</h2>
<p>Authorization 是資料保護與操作安全的核心邊界。它可以用 role、permission、policy、<a href="/blog/backend/knowledge-cards/tenant-boundary/" data-link-title="Tenant Boundary" data-link-desc="說明多租戶系統如何隔離不同客戶或組織的資料與資源">tenant boundary</a>、resource owner 或 attribute-based rule 表達。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<p>系統需要授權模型的訊號是角色、資料範圍或操作風險開始分級。客服可以查看訂單狀態，但調整退款、下載 <a href="/blog/backend/knowledge-cards/pii/" data-link-title="PII" data-link-desc="說明可識別個人的資料如何影響權限、遮罩、保留與稽核">PII</a> 或修改權限應需要更高權限與 <a href="/blog/backend/knowledge-cards/audit-log/" data-link-title="Audit Log" data-link-desc="說明高風險操作如何留下可追溯、可稽核的紀錄">audit log</a>。</p>
<h2 id="設計責任">設計責任</h2>
<p>授權設計要定義主體、資源、操作、條件、拒絕原因與稽核欄位。測試要覆蓋跨 tenant 存取、低權限升級、高風險操作、<a href="/blog/backend/knowledge-cards/function-level-authorization/" data-link-title="Function-Level Authorization" data-link-desc="說明功能操作本身也需要授權，不只資源 ID 需要授權">function-level authorization</a> 與資料匯出。</p>
]]></content:encoded></item></channel></rss>