<?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/%E5%85%81%E8%A8%B1%E6%B8%85%E5%96%AE/</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, 30 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E5%85%81%E8%A8%B1%E6%B8%85%E5%96%AE/index.xml" rel="self" type="application/rss+xml"/><item><title>Allowlist</title><link>https://tarrragon.github.io/blog/backend/knowledge-cards/allowlist/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/backend/knowledge-cards/allowlist/</guid><description>&lt;p>Allowlist 的核心概念是「以明確條件列出可放行項目，讓例外放行保持可控邊界」。它把放行決策從口頭同意轉成可稽核政策。 可先對照 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/input-validation/" data-link-title="Input Validation" data-link-desc="說明進入系統的資料如何先被檢查格式、範圍與語意">Input Validation&lt;/a>。&lt;/p>
&lt;h2 id="概念位置">概念位置&lt;/h2>
&lt;p>Allowlist 位在 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/input-validation/" data-link-title="Input Validation" data-link-desc="說明進入系統的資料如何先被檢查格式、範圍與語意">Input Validation&lt;/a>、&lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/release-freeze/" data-link-title="Release Freeze" data-link-desc="說明高風險期間如何以凍結策略保護正式環境">Release Freeze&lt;/a> 與 &lt;a href="https://tarrragon.github.io/blog/backend/knowledge-cards/authorization/" data-link-title="Authorization" data-link-desc="說明授權如何判斷誰能對哪些資源執行哪些操作">Authorization&lt;/a> 之間。它可以同時用於請求治理、變更治理與資源治理。&lt;/p>
&lt;h2 id="可觀察訊號">可觀察訊號&lt;/h2>
&lt;p>系統需要 allowlist 的訊號是：&lt;/p>
&lt;ul>
&lt;li>需要在凍結期間保留少量必要變更&lt;/li>
&lt;li>高風險操作需要先符合條件才能執行&lt;/li>
&lt;li>團隊需要限制可用來源、版本或操作集合&lt;/li>
&lt;li>放行規則需要可追蹤與可回顧&lt;/li>
&lt;/ul>
&lt;h2 id="接近真實網路服務的例子">接近真實網路服務的例子&lt;/h2>
&lt;p>release freeze 期間，只允許安全修補版本與回復工具變更進入正式環境；資料匯出流程只允許特定角色與核准任務編號觸發。&lt;/p>
&lt;h2 id="設計責任">設計責任&lt;/h2>
&lt;p>Allowlist 要定義允許對象、限制條件、有效期限、審查者與撤銷機制。放行條件要能被系統驗證，而不是依賴人工記憶。&lt;/p></description><content:encoded><![CDATA[<p>Allowlist 的核心概念是「以明確條件列出可放行項目，讓例外放行保持可控邊界」。它把放行決策從口頭同意轉成可稽核政策。 可先對照 <a href="/blog/backend/knowledge-cards/input-validation/" data-link-title="Input Validation" data-link-desc="說明進入系統的資料如何先被檢查格式、範圍與語意">Input Validation</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>Allowlist 位在 <a href="/blog/backend/knowledge-cards/input-validation/" data-link-title="Input Validation" data-link-desc="說明進入系統的資料如何先被檢查格式、範圍與語意">Input Validation</a>、<a href="/blog/backend/knowledge-cards/release-freeze/" data-link-title="Release Freeze" data-link-desc="說明高風險期間如何以凍結策略保護正式環境">Release Freeze</a> 與 <a href="/blog/backend/knowledge-cards/authorization/" data-link-title="Authorization" data-link-desc="說明授權如何判斷誰能對哪些資源執行哪些操作">Authorization</a> 之間。它可以同時用於請求治理、變更治理與資源治理。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<p>系統需要 allowlist 的訊號是：</p>
<ul>
<li>需要在凍結期間保留少量必要變更</li>
<li>高風險操作需要先符合條件才能執行</li>
<li>團隊需要限制可用來源、版本或操作集合</li>
<li>放行規則需要可追蹤與可回顧</li>
</ul>
<h2 id="接近真實網路服務的例子">接近真實網路服務的例子</h2>
<p>release freeze 期間，只允許安全修補版本與回復工具變更進入正式環境；資料匯出流程只允許特定角色與核准任務編號觸發。</p>
<h2 id="設計責任">設計責任</h2>
<p>Allowlist 要定義允許對象、限制條件、有效期限、審查者與撤銷機制。放行條件要能被系統驗證，而不是依賴人工記憶。</p>
]]></content:encoded></item></channel></rss>