營運 service.gov.uk 子網域 (operating a service.gov.uk subdomains)

政府提供一些不同的數位服務給公民。雖然在使用歷程中的開始和結束會是在 GOV.UK 上，這服務本身通常會架設在其他地方，也因此會需要不同的網域名稱。本頁說明 service.gov.uk 之子網域在架設數位服務方面的用途。

注意：這份文件是寫來做為一份 ‘標準’，因此如 MUST 必須、SHOULD 應該、MAY 可以 和 MUST NOT不得 等用詞的意義是依照 RFC 2119 的定義。

單一進入點

英國政府所提供的每個數位服務在網路上 必須 只有一個廣為人知的位置，當使用者想要使用該服務時可以去那裡找到。那廣為人知的位置會是在 GOV.UK 上相關的開始頁面 — 例如， DVLA 的 tax disc 服務就是在 https://www.gov.uk/tax-disc。

服務的管理者 不得 將那個 GOV.UK 上開始頁面之外的其他網址 當成 該服務的開始點 來對外宣傳。這會被印在宣傳單張上、用在 email 簽名檔和電視廣告上。

一個服務的開始頁網址，會由 GDS 經過 與服務管理者討論 和 對使用者行為、搜尋引擎推薦等相關資料的分析之後 再行配置。

設立一個網域

一個服務的往覆溝通的部份 — 也就是那些當使用者與該服務互動時所動態產生出來的頁面 — 通常不會是架設在 www.gov.uk 這網域下。這意味著每個服務往覆溝通的部份需要它自己的網域名稱。

注意：這原則不適用於 GDS 與其他政府部門所合作開發和維護的那組 GOV.UK 上名為 ‘smart answers’ 的互動工具。

對於在 2013 年四月一日之後上線的所有新的數位政府服務，GDS 會設立一個形式為 servicename.service.gov.uk 的域名 (其中 “servicename” 是一個相關部門/單位與 Government Digital Service 取得共識而定的一個對此服務的英文簡述)。這會為所有數位服務的中央政府域名帶來一致性，並去除了對部門子網域的依賴 (這樣的依賴會受到政府組織架構改變的影響) 和對現已退役之 DirectGov 和 BusinessLink 等線上品牌的依賴。

取得一個 service.gov.uk 子域名的程序 可由兩種不同的情境開始：一個是當服務管理者向 Government Digital Service 的產品經理索取一個 GOV.UK 上的開始頁面時 (對於在 2013 年三月十三日時正在進行的服務而言)、另一個是當服務管理者經由填寫 GOV.UK 服務台的政府聯繫表單去要求建立一個子域名時 (這是對 2013 年三月十三日之後開始開發的服務)。 service.gov.uk 的子域名 應該 要描述該服務 (例如 lastingpowerofattorney.service.gov.uk ) 且不應該包含該服務所屬的部門或單位的名稱 (例如 ministryofmagicwandregistration.service.gov.uk )。

服務的所屬部門/單位將會被授予權限去管理該網域或其子網域，雖然有些情況下這些會交由第三方供應商來執行。

子網域

關於一個服務管理者在拿到 servicename.service.gov.uk 的管控權之後該建立什麼子網域，這一節列出一些指引。

看得到的子網域的最大數量

與使用者直接面對的線上即時服務 應該 最多以三個使用者看得到的 servicename.service.gov.uk 子網域來運作：

• www.servicename.service.gov.uk 是給構成你服務的那些直接面對公眾的即時動態產生的網頁。
• assets.servicename.service.gov.uk 是用來放例如靜態圖檔、共享的 JavaScript 等服務在進行中會用到的資源檔案 (注意：關於這服務的文字性內容，例如資格的引導或申請人的細則，則 應該 放在 GOV.UK 上)
• admin.servicename.service.gov.uk 是放一些功能，讓非技術人員可以執行服務 (例如：聯絡中心的員工可以用這個子域名去存取和處理一些需要人工判斷的工作項目)

你 不應該 為 application programming interfaces (APIs) 建立個別的網域，除非真的有很好的理由要有一個完全分開的網域。 (真的這麼適合理由很少很少)

如果你想在除了上列的三種使用者看得到的子網域之外建立新的，服務管理者應該 (透過你的 transformation team contact) 通知 Government Digital Service 的技術架構師。除了主流的互動服務，我們也正在為一些比較非常態的系統設計建立模式，而且我們也隨時可以針對例外或特殊案例進行討論。

使用者名稱和密碼

如果服務還在 private alpha 或 private beta 的階段，那它應該要以只有開發團隊和測試人員知道的帳號和密碼保護起來。如果一項服務、或該服務的部份 進入了 public alpha 或 beta 階段，那麼它應該在每個頁面上和每個 API 回應中以文字標籤明確標示 (也就是說，不要用裡面寫著 alpha 或 beta 文字的圖片)。

多重環境

對任何服務而言，為開發、測試、上線的版本準備多種的 ‘環境’ 是很好的實務。開發和測試環境讓團隊可以在一個服務上線前評估正確性和品質。一般而言，用來存取開發和測試版之服務的子域名 架構方式和上線版之服務的子域名一樣。

因此，你 可以 為了測試和開發的用途在 servicename.service.gov.uk 下建立其他子域名，例如 www-preview. 和 www-dev.，或 www.preview. 和 www.dev.。如果有很強有力的理由要用一個非 .gov.uk 的網域來做測試及/或開發用子網域，那也可以接受。

不管用什麼網域名稱，測試和開發網域上的 web-based 服務 (包含 APIs) 應該要以 private alpha 和 beta 階段一樣的使用者名稱和密碼來保護。

Transport Layer Security

許多服務會需要向使用者索取得個人資料。確保惡意的第三方無法在這些資料正經由網路傳送的過程中加以攔劫，是非常重要的。

因此，所有經由 service.gov.uk 網域來存取的服務 (包含各種 API) 必須 只能透過安全的連線。這對於 web-based 的服務而言，
就是只能使用 HTTPS 連線 (這些安全連線是建立在一種縮寫為 TLS 或 SSL 的協定之上，所以我們也常常用這兩個縮寫去稱呼之)。
所有服務在任何情況下都不能接受 HTTP 連線。

一旦一個服務的管理者確認了他們的 HTTPS 設置可以順利運作，他們 應該 在 production 網域 (如 www., admin. 和 assets.) 上
以設置一個如下的 HTTP response header 來啟用 HSTS。

Strict-Transport-Security: max-age=1209600, includeSubDomains;

代表一個 14 天內只用 HTTPS 連線的承諾。一旦服務管理者確信 HSTS 設定正確，你 應該 將這承諾延長至月或年：

Strict-Transport-Security: max-age=31536000, includeSubDomains;

Cookies

用在 www.servicename.service.gov.uk 和 admin.servicename.service.gov.uk 的 cookies 必須 要把適用範圍限制於只在原來的網域。Cookie 不得 將適用範圍擴大到 servicename.service.gov.uk 的網域。

Cookies 不應該 用於 assets.servicename.service.gov.uk (因為這樣會造成瀏覽器的額外負擔、造成回應使用者的時間變慢卻又沒為服務管理者提供什麼好處。)

Cookies 送出時 必須 要設有 Secure 屬性，而且在時機適當的時候也要設有 HttpOnly 屬性。這些屬性設定對瀏覽器處理 cookies 的方式提供了更多的安全保障。

robots.txt 和 根階層網頁重導向

GOVV.UK 是讓使用者尋找所有政府服務的地方，所以很重要是得確保使用者總是從相關的 GOV.UK 頁面上開始、而不是從一個位於 www.servicename.service.gov.uk 上不同的或重覆的開始頁面。

因此，所有服務要告知搜尋引擎不要建立此服務在自己的網域上之資料索引，這樣一來在搜尋引擎的搜尋結果排名上 相關的 GOV.UK 頁面才不會和這服務的網域發生競爭。要達成這樣的效果，可以將直接連往該服務之網域的使用者重導向到相關的 GOV.UK 上的開始頁面，以及要求搜尋引擎不要去建立這個服務的網域上之資料索引。所以，每個架設在一個 service.gov.uk 網域裡的服務 必須：

• 放一個 robots.txt 檔在 www, admin 和 assets 子網域上，以要求搜尋引擎不要為這網站建立任何資料索引。下面是一個 robots.txt 的範例，而更多的細節說明可以在 The Web Robots Pages 上找到：User-agent: *
  Disallow: /
• 設定一個 HTTP 301 網頁重導向，從 www 和 assets 的根階層索引頁將使用者重導向到 GOV.UK 上相關的開始頁面。 (注意：這意味著這服務在 GOV.UK 上的開始頁面 不應該 有連結連向 www 網域之根階層。)

讓 CDN-based 之 DDOS 保護服務供應商來連線的源頭伺服器

如果你有簽約請 CDN-based DDOS-protection 的供應商提供服務，那你應該要額外註冊如下這些子域名給你的供應商使用：

*[DDOS]: Distributed Denial of Service，分散式阻斷服務攻擊
*[CDN]: Content Delivery Network，內容傳遞網路

• www-production.servicename.service.gov.uk
• admin-production.servicename.service.gov.uk
• assets-production.servicename.service.gov.uk

你的供應商會用這些子域名在網路上尋找你的 www, admin 和 assets 等服務。

源頭伺服器的詳細設定建議不在本文件的討論範圍內，但重點在於要確保這些 ‘源頭網域’ 只接受來自受信任之來源的連線，如：

• DDOS 保護服務供應商的伺服器
• 這服務本身的開發地點或管理地點

目前，對於會傳輸個人資料之互動服務，我們建議不要讓 SSL 連線加密終止於 DDOS 保護服務供應商的伺服器上，但現階段並不這麼強制要求。雖然，將 SSL 連線加密終止在第三方的網路上，可以允許供應商進行更深入的分析、額外對某些攻擊類型提供抒解，但這也會讓供應商得有機會取得所有要傳送進你服務的個人資料。

允許這層級的存取權有很顯然的壞處，特別是如果供應商的網路和工作流程的安全層級尚未被認定為能高到這服務的其他部份同等時。這是個帶有風險的決定，但如果心有疑慮，我們還是建議不要讓 SSL 連線加密在第三方網路上終止。

許多供應商提供 IP 轉發式的 DDOS 保護，這樣就不會有 SSL 連線終止的安全性問題，因此比較推薦這種方式的 DDOS 保護。如果你的服務需要監控互動進行過程 (這跟 DDOS 保護是完全不同的一回事)，你該尋求你 CESG account manager 的建議。這指引是暫時性的，很快會被更新 — 2013 年五月初時請再次回來看更新內容。

寄 Email 給服務的使用者

寄 Email 給使用你服務的使用者時，應該 要用會有真人收發的電子信箱、且此信箱要是來自 servicename.service.gov.uk 之下 (而不是負責的部門/單位或其他的域名)。

你 應該 在發信的那個網域啟用 SPF。如果你想要的話，也 可以 在發信的那個網域用 DKIM，這可以提高信件的寄達率、並幫助收件人更容易分辨信件的真偽。

服務子網域的生命週期

如果你的服務因為任何原因而需要步入尾聲，你 必須 要以下列的方式確保服務和資訊對使用者持續有用：

• 繼續使用 SSL 加密連線
• 給出一個網頁重導向，將使用者從你的服務轉回到 GOV.UK 上的開始頁面。

對於上線不到六個月的服務，你 必須 將上述兩點做足到從上線開始滿一年的日子。對於上線超過六個月的服務，你 必須 將上述兩點再繼續做十二個月、或一直做到目前的 SSL 憑證到期，看兩者哪個比較短。

GOV.UK 上的開始頁面也會加以增修，以解釋這項服務將很快不再運行，並且不再放一個開始按鈕去指向那個停用的服務。

*[SPF]: Sender Policy Framework
*[DKIM]: DomainKeys Identified Mail
*[APIs]: application programming interfaces, 應用程式介面
*[API]: application programming interface, 應用程式介面

譯者：盧紀憲
校稿者：
原始出處：https://www.gov.uk/service-manual/operations/operating-servicegovuk-subdomains/