【2026 CIO&CISO大調查】39％企業今年要擴大AP上雲規模， SaaS訂閱費用成企業公雲預算大宗

來源：https://www.ithome.com.tw/news/175830

生成式AI浪潮持續加速了企業上雲的腳步，也開始改變企業上雲的模式。今年高達39％的企業要擴大AP上雲的規模，更有18%金融業者今年開始將自家應用搬上公雲。SaaS服務投資的比重成了企業公雲預算的大宗，訂閱管理成了企業IT的新課題。

立即下載完整報告

【iThome 2026 CIO & CISO大調查】 雲端架構策略布局篇完整報告

根據iThome 2026 CIO&CISO大調查，臺灣企業平均將21%的企業應用部署在公雲環境，又以服務業最高，平均將三分之一的應用上雲。

今年要擴大AP上雲規模的企業，多達39%，百億營收企業更是每兩家就有一家要擴大上雲規模。今年也有不少企業是上雲新手，像是18%金融業者今年才開始要將AP搬上公雲環境部署。

企業2026年的公雲預算，平均4,294萬元，比去年穩定增加了5%，但出現了兩極化的產業差異。醫療業和金融業大幅加碼，雲端化程度最高的服務業，今年只小幅增加了2%的雲端預算。高科技業、製造業和政府學校的雲端預算不增反減，高科技製造業甚至比去年少了1成多。

企業今年平均4,294萬元的公雲預算中，主要包括了公雲Infra預算2,028萬元，和公雲SaaS的預算2,266萬元，SaaS佔了公雲預算的53%，超過半數。除了政府學校以外，其餘五大產業的SaaS預算都有成長，又以醫療業成長力道最多，達到18%。

相較於SaaS預算的成長，多個產業的公雲Infra預算則明顯下滑，高科技製造業下滑了27%，政府學校和一般製造業都大約比去年減少了一成。

醫療業是今年最積極上雲的產業，2022年，政府開放電子病歷上雲後，掀起了醫院第一波上雲潮，在2024年達到巔峰，醫療業雲端投資成長率高達96%，到了2025年，醫療公雲預算成長率減少到31%。2026年，醫療業的GenAI應用需求爆發，再加上政府推動新一波醫療資料交換標準FHIR的趨力，掀起了第二波上雲潮。不少醫療業不只押寶一朵公雲，今年多了1成醫療業者要採用多雲混合雲架構。

金融業今年也是公雲Infra和公雲SaaS預算雙漲的產業，但是相較於醫療業的爆發式成長，金融業則顯得審慎投資。

金融業同樣是在主管機關的法規鬆綁下，開始積極上雲，更在金融韌性政策方向的驅使下，格外重視雲端備援的建置。金管會在2019年首度鬆綁金融上雲的規範，以委外管理方式來納管各項金融上雲的核准，但因申請作業漫長，削弱了金融上雲的意願。直到2023年，金管會統一了銀行、保險與證券等金融三業的上雲規範，更大幅簡化上雲申請的作業，終於掀起了一波金融上雲潮，根據iThome在2024年的調查，該年金融公雲Infra預算比前一年足足增加了105%。2025年，金融Infra上雲預算仍有56%的成長率，仍有不少積極上雲的金融業者。

不過，到了今年iThome CIO大調查發現，2026年金融業公雲Infra預算雖然仍舊正成長，但只比去年增加了11%，金融業對公雲Infra的投資轉為謹慎。

從另一個技術採用趨勢，更可以看到金融業上雲轉趨謹慎的態度變化。今年有11%金融業要導入FinOps雲端維運成本管理，希望能更有效控管公雲用量和花費。

值得關注的是去年才在臺商用的衛星網路，今年開始有一些企業想要嘗試，幾乎各產業都有企業想用，像是金融業今年有5%企業想用，高科技業者也有3%的企業要試。

立即下載完整報告

【iThome 2026 CIO & CISO大調查】 雲端架構策略布局篇完整報告

'

英國國民保健署因AI資安疑慮，將部分GitHub公開儲存庫改設私有

來源：https://www.ithome.com.tw/news/175818

為因應先進AI模型可能帶來的資安風險，英國國民保健署（NHS） 要求技術主管暫時限制部分開放原始碼專案的公開存取權限。

根據The Register報導，NHS內部指引要求：在5月11日前，相關GitHub儲存庫必須由公開狀態改設為私有；除非有明確且特殊需求，否則不應維持公開，影響的GitHub 儲存庫數量達數百個。

這份內部指引指出，公開儲存庫可能增加原始碼、架構決策、組態細節與上下文資訊（ contextual information）外洩的風險；在AI模型已能大規模擷取程式碼 ，並進行推論與分析的情況下，這些資訊可能遭到濫用。 指引中特別提到Anthropic的AI模型Mythos。NH S England發言人表示，這只是暫時性措施，目的是在評估AI 模型快速發展影響的同時，進一步強化資安；若有明確需求，NHS 仍會繼續發布原始碼。

NHS服務手冊主張，公共服務由公眾的資金打造，除非有充分理由， 相關程式碼應開放給他人重複使用與延伸建置， 以避免重複開發並降低對單一供應商的依賴。這次NHS暫時將部分公開儲存庫改為私有， 也使其長期偏向開放原始碼的政策方向受到關注。

英國NHS前開放技術主管Terence Eden則認為，將公開儲存庫改設私有，無法有效防範先進AI能 力。Eden指出，許多開放原始碼早已被封存或納入訓練資料， 真正的風險反而可能來自軟體供應鏈、網路釣魚、 密碼管理不當與內部威脅。

'

AWS Kiro加入需求分析，AI實作前先找出需求歧義與衝突

來源：https://www.ithome.com.tw/news/175820

AWS團隊更新AI開發工具Kiro IDE的規格開發流程，新增需求分析、快速規畫模式和平行任務執行，該更新讓系統在開始編寫程式前，先協助開發者找出需求描述中的模糊處、邏輯衝突與未說清楚的條件，降低後續實作走錯方向的機率。 官方也表示，部分大型規格的完整實作時間可由超過1小時，降至原本約四分之一。

Kiro是一款協助開發者用AI產生和執行程式任務的開發工具，採用規格驅動開發方法，也就是先定義需求、設計和任務清單，再讓AI依照這些文件進行實作。這種方式有助於讓開發過程留下依據，但在功能範圍已經明確，或多項工作彼此獨立時，也可能拖慢流程。

新版Kiro加入的深度需求分析功能，可在系統產生需求後，由開發者啟動檢查。Kiro團隊表示，該功能採用混合式神經符號人工智慧（Neurosymbolic AI），結合大型語言模型與自動化推理，檢查需求是否存在不同解讀或互相矛盾的規則，或沒有交代清楚的情境，例如需求寫著「移除紀錄」時，實際上可能是永久刪除，也可能是保留資料但標記為刪除，而Kiro會把這類歧義整理成選項，讓開發者確認真正意圖。

快速規畫模式則用來縮短建立規格的時間。過去Kiro會依序產生需求、設計與任務清單，並要求使用者逐步確認，而新模式會先掃描專案使用的程式語言、框架與結構，再提出2到4個釐清問題，接著一次產生需求、設計和任務，作為AI後續執行的依據。如果使用者只修改任務，Kiro就只重新產生任務，要是修改設計，便重新產生設計與任務，若改變整體範圍，才重新執行完整流程。

平行任務執行用於一次執行整份任務清單，Kiro會分析每項工作的相依關係，判斷可同時進行的任務與必須等待前一項完成的任務。會修改同一批檔案的任務不會並行，基礎設定會先處理，測試則會等相關程式碼完成後再執行。每項任務都會在隔離環境中進行，因此即使其中一項失敗，其他不受影響的任務仍可繼續執行。

'

DNSSEC簽章錯誤導致德國.de網域大規模故障，數百萬網站斷線數小時

來源：https://www.ithome.com.tw/news/175822

5月5日晚間，德國頂級網域（ccTLD）「.de」發生大規模DNS異常事件，大量德國網站的網域名稱當時無法解析。根據網路服務與資安業者Cloudflare的報告指出，事件起因是德國網域管理機構DENIC發布錯誤的DNSSEC數位簽章，導致DNS伺服器的DNSSEC驗證失敗，數百萬個採用.de網域的網站同時斷線，Cloudflare隨即啟用「負向信任錨」（Negative Trust Anchors，NTA）機制緩解問題。

網域名稱系統安全擴充（Domain Name System Security Extensions，DNSSEC）機制存在的目的，是透過數位簽章技術驗證DNS記錄完整性，確保網域名稱解析過程未被竄改，藉此建立從根區域（Root Zone）延伸至各級網域的信任鏈。然而，一旦頂級網域出現錯誤，便會連帶影響其下所有網域。

Cloudflare指出，這次事故的起因，在於德國網域註冊管理機構DENIC於UTC時間5月5日19點30分左右，開始發布異常的RRSIG簽章紀錄，依據DNSSEC規範，任何接收到這些簽章的DNS驗證解析器，都必須拒絕回應查詢並回傳SERVFAIL錯誤，Cloudflare營運的公共DNS解析器1.1.1.1也不例外，進而導致德國大量網站服務中斷。

為降低影響，Cloudflare緊急啟用兩項因應措施，其一，是透過公共DNS解析器1.1.1.1提供仍存放於快取中的過期DNS紀錄，而不是回傳錯誤，暫時維持用戶的DNS查詢作業，爭取應變處理時間。其次， ，是從UTC時間22點17分啟用「負向信任錨」（NTA）機制，暫時停用.de網域的DNSSEC驗證，使DNS解析器能繼續回應DNS查詢，藉此恢復網站連線能力。但Cloudflare表示，這個緩解手段有風險，因為停用DNSSEC驗證後，將導致.de網域在事件期間更容易遭受攻擊。

DENIC從UTC時間5月6日零點8分開始，發布正確的DNS區域資料，稍後.de網域在1點15分完全恢復運作，整個事故為期大約5小時。

DENIC在5月6日發布的事後報告中，解釋這次事故的起因，是在例行性的DNSSEC金鑰輪替（key rollover）過程中，系統產生並散布「無法驗證」的DNSSEC簽章（non-validatable signatures）。作為預防措施，他們已暫停金鑰輪換，直至查明確切的技術原因。

接著DENIC在5月8日揭露更詳細的調查結果，表示問題源自DNSSEC簽章系統的金鑰產生過程出錯。這套系統是由標準DNS軟體Knot、自行開發的程式與HSM（硬體安全模組）共同組成，2026年4月新上線第三代DNSSEC簽章系統中，含有一段未在測試中發現的程式碼錯誤，導致同1個金鑰識別碼（key tag）卻對應到3組金鑰配對（key pairs），DNS系統中的DNSKEY紀錄只發布其中1組金鑰，然而，有三分之二的RRSIG簽章是基於其餘兩組金鑰，進而導致這些RRSIG的DNSSEC驗證失敗。

Cloudflare表示，這次事件凸顯DNSSEC雖能提升DNS安全性，然而一旦頂級網域的簽章出錯，問題就可能往下層網域蔓延，造成大規模網路服務中斷。但這個問題並無簡單的解決方法，業界能做的就是在事件發生時， 迅速且不斷地處理，例如他們啟用負向信任錨機制。

'