美國平等就業機會委員會(Equal Employment Opportunity Commission, EEOC)於2023年5月18日發布「根據 1964 年《民權法》第七章評估就業篩選程序中使用軟體、演算法和AI之不利影響」(Assessing Adverse Impact in Software, Algorithms, and Artificial Intelligence Used in Employment Selection Procedures Under Title VII of the Civil Rights Act of 1964)之技術輔助文件(下簡稱「技術輔助文件」),以防止雇主使用自動化系統(automated systems)對求職者及員工做出歧視決定。
該技術輔助文件為EEOC於2021年推動「AI與演算法公平倡議」(Artificial Intelligence and Algorithmic Fairness Initiative)計畫的成果之一,旨在確保招募或其他就業決策軟體符合民權法要求,並根據EEOC 1978年公布之「受僱人篩選程序統一指引」(Uniform Guidelines on Employee Selection Procedures, UGESP),說明雇主將自動化系統納入就業決策所應注意事項。
當雇主對求職者與員工做出是否僱用、晉升、終止僱傭,或採取類似行動之決定,是透過演算法決策工具(algorithmic decision-making tool),對特定種族、膚色、宗教、性別、國籍或特定特徵組合(如亞洲女性),做出篩選並產生不利影響時,除非雇主能證明該決策與職位工作內容有關並符合業務需求,且無其他替代方案,否則此決策將違反《民權法》第七章規定。
針對如何評估不利影響,雇主得依UGESP「五分之四法則」(four-fifths rule),初步判斷演算法決策工具是否對某些族群產生顯著較低的篩選率。惟EEOC提醒五分之四法則推導出之篩選率差異較高時,仍有可能導致不利影響,雇主應依個案考量,使用實務常見的「統計顯著性」(statistical significance)等方法進一步判斷。
其次,當演算法決策工具係由外部供應商所開發,或由雇主授權管理人管理時,雇主不得以信賴供應商或管理人陳述為由規避《民權法》第七章,其仍應為供應商開發與管理人管理演算法決策工具所產生之歧視結果負責。
最後,EEOC鼓勵雇主應對演算法決策工具進行持續性自我評估,若發現該工具將產生不利影響,雇主得採取措施以減少不利影響或選擇不同工具,以避免違反《民權法》第七章。
歐盟「藥品法規包裹法案」(Pharma Package)重點說明與簡析 資訊工業策進會科技法律研究所 2025年09月10日 歐盟理事會(the Council of the European Union)於2025年6月4日就歐盟「藥品法規包裹法案」(Pharma Package)取得一致立場,且正與歐洲議會及歐盟執委會展開三方協商(trilogue),以共同研議最終立法版本[1]。法案預計於2026年初進行表決,若順利通過且加上過渡期,最快將於2028年正式施行,並可能重塑歐盟藥品市場之上市與投資規劃。 壹、背景摘要 有鑑於歐盟現行的藥品法規制度,自2004年修正後施行至今已逾20年,難以充分回應公共衛生需求、藥品可及性落差以及國際市場競爭等多重挑戰。因此,歐盟執委會(European Commission, EC)於2023年4月公布「藥品法規包裹法案」,旨在強化藥品供應鏈穩定性、提升藥品創新與競爭力,以建立更公平、具韌性與永續性的歐洲醫藥市場[2]。而2024年4月歐洲議會(European Parliament)[3]、2025年6月歐盟理事會亦分別提出不同版本,以促進歐洲整合為單一藥品市場。 本次改革對生技製藥產業影響深遠,為協助我國製藥產業在進入歐洲市場前先行掌握相關動向,以下將進行重點說明與分析。 貳、立法重點與比較 一、藥品監管保護期間之修正 在本次藥品法規包裹法案中,有關藥品監管保護期間之修正,為歐盟執委會、歐洲議會與歐盟理事會分歧最大,也是外界高度關注之核心重點。首先,現行歐盟新藥保護是由8年資料專屬保護期(Regulatory Data Protection, RDP)[4]與2年市場獨占期(Market Exclusivity, ME)所構成[5],若於資料專屬保護期間內取得新適應症可再延長1年市場獨占期,亦即保護期共為10~11年。 歐盟執委會則提議將資料專屬保護期縮短至6年,並搭配延長誘因機制,最多可再延長3年,條件包含: 1.滿足現有醫療需求可延長0.5年。 2.藥品在所有歐盟成員國上市可延長2年。 3.進行比較性臨床試驗可延長0.5年。 此外,不同於現行制度將新適應症延長1年納入市場獨占期,歐盟執委會則提議將此移至資料專屬保護期,因此合併原有2年市場獨占期後,保護期共為8~12年。 反之,歐洲議會則擬將資料專屬保護期調整為7.5年,並同樣設有延長誘因機制,但總延長上限至多1年,條件包含: 1.滿足現有醫療需求可延長1年。 2.進行比較性臨床試驗可延長0.5年。 3.在歐盟境內透過公私協力進行研發可延長0.5年。 若公司另取得比現有療法更有顯著臨床優勢之新適應症,則原有2年市場獨占期可再延長1年,合併計算後保護期共為9.5~11.5年。 而歐盟理事會則不同於歐盟執委會、歐洲議會,選擇將資料專屬保護期維持現行8年,但無法再延長。然而,市場獨占期則提議縮減為1年,但若符合特定條件則可再延長至2年,合併計算後保護期共為9~10年。條件包括: 1.滿足現有醫療需求。 2.產品含有新活性物質,並同時符合以下3項要件: (1)上市許可申請具關聯性且有證據基礎的比較性臨床試驗結果作為支持。 (2)在一個以上的歐盟成員國內進行臨床試驗。 (3)申請人須證明已優先於歐盟申請上市許可,或於首次向歐盟以外地區提出申請後90日內完成歐盟上市申請。 圖一、歐盟藥品法規包裹法案提議版本比較 資料來源:本研究整理 二、針對抗菌藥物引入創新研發機制 抗菌藥物抗藥性(Antimicrobial resistance, AMR)為近年全球公共衛生重要議題,並為世界衛生組織(World Health Organization, WHO)所列全球十大健康威脅之一[6]。因此,除嚴格限制抗菌藥物濫用外,為有效促進新型抗菌藥物之研發,本次藥品法規包裹法案中亦引入「可轉讓資料專屬保護權憑證」(Transferable Exclusivity Voucher, TEV)作為獎勵措施。 使用此憑證可賦予持有人額外1年資料專屬保護期,且除可用於抗菌藥品外,亦可適用於公司內其他更具商業價值藥品,或將此憑證轉賣給其他藥廠,為藥廠提供額外收入,但每張憑證僅能轉讓一次。 考量到憑證可能被用於商業利益龐大之藥品,藉此延緩學名藥與生物相似藥進入市場,並影響病患取得藥物之可及性,歐盟執委會於提議時亦強調此制度預計僅實施15年,或至多核發10張憑證後即停止適用[7]。此外,在歐盟執委會所提議之版本中,對於憑證使用亦設有限制,包含必須於憑證核發後5年內使用,且僅限用於尚在資料專屬保護期前4年之藥品,以確保市場可預測性。 歐洲議會與歐盟理事會雖然大致表態支持,但對憑證效力採取不同立場。歐洲議會態度較為保留,其提議使用憑證所額外延長之資料專屬保護期應依據抗菌藥品優先等級區分為6個月、9個月或12個月,且同樣受有總延長至多1年之限制。換言之,在歐洲議會提議版本下,無論延長事由為何,資料專屬保護期至多僅能延長至8.5年。 相對而言,歐盟理事會並未採納歐洲議會之提議,而是維持歐盟執委會提出增加1年資料專屬保護期之優惠設計。然而,為避免過度限制市場競爭,歐盟理事會亦新增規定,若憑證用於非抗菌藥品,則僅能在該藥品資料專屬保護期的第5年使用,且須證明過去4年內該藥品任一年銷售額均未超過4.9億歐元。 參、總結 「藥品法規包裹法案」反映出歐盟執委會、歐洲議會與歐盟理事會對新藥保護政策之差異,雖然三者皆試圖在鼓勵創新研發與提升藥品可近性之間取得平衡,但在藥品監管保護期間具體設計上仍有差異。歐盟執委會雖提議縮減資料專屬保護期,但也透過延長制度維持研發誘因。而歐洲議會則提議更高的初始保護門檻,但限制總延長期,且更著重在鼓勵研發活動而非市場擴張。至於歐盟理事會則維持現行保護年限,以持續激勵研發投入,但也透過縮短市場獨占期,加速學名藥與生物相似藥上市,以降低藥品價格並滿足醫療需求。 至於「可轉讓資料專屬保護權憑證」制度固然能為抗菌藥物提供研發誘因,但也伴隨著一定的潛在風險與利益分配爭議,如何確保該制度所帶來之公共利益超過公共衛生成本與風險,仍取決於未來最終立法版本應該如何調整與落實。對於我國製藥產業而言,此次改革有可能加速學名藥與生物相似藥進入歐洲市場,亦可能因延長誘因制度而遲延競爭時機,故仍應持續密切關注並審慎調整研發與市場策略。 [1]EUROPEAN COUNCIL, ‘Pharma package’: Council agrees its position on new rules for a fairer and more competitive EU pharmaceutical sector (2025), https://www.consilium.europa.eu/en/press/press-releases/2025/06/04/pharma-package-council-agrees-its-position-on-new-rules-for-a-fairer-and-more-competitive-eu-pharmaceutical-sector/#:~:text=The%20Council's%20position&text=obligation%20to%20supply%3A%20a%20new,patients%20in%20the%20member%20state (last visited Aug. 28, 2025). [2]EUROPEAN COMMISSION [EC], Reform of the EU pharmaceutical legislation (2023), https://health.ec.europa.eu/medicinal-products/legal-framework-governing-medicinal-products-human-use-eu/reform-eu-pharmaceutical-legislation_en (last visited Aug. 28, 2025). [3]EUROPEAN PARLIAMENT, Parliament adopts its position on EU pharmaceutical reform (2024), https://www.europarl.europa.eu/news/en/press-room/20240408IPR20308/parliament-adopts-its-position-on-eu-pharmaceutical-reform (last visited Aug. 28, 2025). [4]「資料專屬保護期」是指專利藥提出新藥上市申請時,所檢附證明藥品安全性與療效之相關申請數據資料,其他藥廠非經原廠同意,於法定保護期間內不得引用,為行政機關針對原廠新藥上市申請資料給予之保護權益。詳請參考:台灣光鹽生物學苑,〈【醫藥小專欄】什麼是資料專屬權(data exclusivity)〉,台灣光鹽生物學苑,https://www.biotech-edu.com/%E3%80%90%E9%86%AB%E8%97%A5%E5%B0%8F%E5%B0%88%E6%AC%84%E3%80%91%E4%BB%80%E9%BA%BC%E6%98%AF%E8%B3%87%EF%A6%BE%E5%B0%88%E5%B1%AC%E6%AC%8A-data-exclusivity/ (最後瀏覽日:2025/08/28)。 [5]「市場獨占期」則是指在一定期間內,即使學名藥或生物相似藥已可向主管機關提出上市許可之申請並獲得核准,但仍不得實質上市銷售,須直到市場獨占期屆滿為止。市場獨占期與資料專屬保護期之比較,詳請參考:Specialist Pharmacy Service, Understanding data exclusivity and market protection (2025), https://www.sps.nhs.uk/articles/understanding-data-exclusivity-and-market-protection/ (last visited Aug. 28, 2025). [6]〈世界抗生素週〉,衛生福利部疾病管制署,https://www.cdc.gov.tw/En/Category/MPage/t2VWXn93ooNVJPuQRF7jzg (最後瀏覽日:2025/08/28) [7]CROWELL & MORING LLP, The New EU “Pharma Package”: The transferable exclusivity voucher—A comparison of Commission/Parliament/Council positions(2025),https://www.crowell.com/en/insights/client-alerts/the-new-eu-pharma-package-the-transferable-exclusivity-vouchera-comparison-of-commissionparliamentcouncil-positions (last visited Aug. 28, 2025).
WTO歐盟生技產品案解析(下) 歐盟執委會公布「數位金融包裹」法案為鼓勵金融產業之創新,同時使其遵循應有之責任,並讓歐盟金融消費者與商業機構享有更多之利益,歐盟執委會於2020年10月24日提出數位金融包裹法案(Digital Finance Package),並提出以下2項數位金融立法提案: 一、加密資產立法提案(Proposal for Markets in Crypto-assets) 為促進金融創新並同時保有金融穩定性與保護投資人,歐盟執委會提出加密資產管制框架立法提案,並將加密資產分為已受監管與未受監管兩類,前者將持續依據既有規範進行管理。而針對尚未管制之加密資產,該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制,要求取得核准後始可提供服務。具體而言之,立法提案包含以下項目: (一)針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。 (二)針對向公開市場提供加密資產進行管制,例如,依據提案第4條,供應商應為法人,第5條則要求供應商應製作加密資產白皮書,並將其提供給主管機關後始可於公開市場提供相關服務。 (三)針對代幣資產發行人以及其加密資產之審核程序,依據提案第15條,代幣發行者必須為歐盟境內之法律實體。另外,該法要求加密資產發行人應誠實、公平且專業,並完成加密資產白皮書之出版與制定市場溝通規則。 (四)針對加密資產之收購,該法第4章亦設有相關規範,於第37條及38條規定收購之評估機制。 (五)針對加密資產服務供應商之授權與營運條件,該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。 (六)針對市場秩序維護之部分,該法於第6章規範相關預防市場濫用之禁止事項與要求,並於第7章賦予歐盟成員國各主管機關相關權力,例如第94條之監督與懲處權限。 二、歐盟數位營運韌性管制框架立法提案(Proposal for Digital Operational Resilience) 數位化總伴隨資安風險,歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案,以確保相關企業可應對所有與通訊技術有關之干擾與威脅,另外,銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊,另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含: (一)ICT風險管理要求:該立法提案參照相關國際標準,於第5至第14條制訂相關ICT風險管理要求,惟未要求應遵循具體國際標準。 (二)ICT相關事件報告:該提案於第15至20條規範相關報告義務,將整合歐盟金融機構之ICT相關事件報告與監測程序。 (三)數位運作韌性測試:該提案於第21至第24條要求ICT風險管理框架應定期進行測試,惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。 (四)第三方單位風險:該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測,例如,第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範,另外,ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。
解析雲端運算有關認驗證機制與資安標準發展解析雲端運算有關認驗證機制與資安標準發展 科技法律研究所 2013年12月04日 壹、前言 2013上半年度報載「新北市成為全球首個雲端安全認證之政府機構」[1],新北市政府獲得國際組織雲端安全聯盟( Cloud Security Alliance, CSA )評定為全球第一個通過「雲端安全開放式認證架構」之政府機構,獲頒「2013雲端安全耀星獎」(2013 Cloud Security STAR Award),該獎項一向是頒發給在雲端運用與安全上具有重要貢獻及示範作用之國際企業,今年度除了頒發給旗下擁有年營業額高達1200億台幣「淘寶網」的阿里巴巴集團外,首度將獎項頒發給政府組織。究竟何謂雲端認證,其背景、精神與機制運作為何?本文以雲端運算相關資訊安全標準的推動為主題,並介紹幾個具有指標性的驗證機制,以使讀者能瞭解雲端運算環境中的資安議題及相關機制的運作。 資訊安全向來是雲端運算服務中最重要的議題之一,各國推展雲端運算產業之際,會以提出指引或指導原則方式作為參考基準,讓產業有相關的資訊安全依循標準。另一方面,相關的產業團體也會進行促成資訊安全標準形成的活動,直至資訊安全相關作法或基準的討論成熟之後,則可能研提至國際組織討論制定相關標準。 貳、雲端運算資訊安全之控制依循 雲端運算的資訊安全風險,可從政策與組織、技術與法律層面來觀察[2],涉及層面相當廣泛,包括雲端使用者實質控制能力的弱化、雲端服務資訊格式與平台未互通所導致的閉鎖效應(Lock-in)、以及雲端服務提供者內部控管不善…等,都是可能發生的實質資安問題 。 在雲端運算產業甫推動之初,各先進國以提出指引的方式,作為產業輔導的基礎,並強化使用者對雲端運算的基本認知,並以「分析雲端運算特色及特有風險」及「尋求適於雲端運算的資訊安全標準」為重心。 一、ENISA「資訊安全確保架構」[3] 歐盟網路與資訊安全機關(European Network and Information Security Agency, ENISA)於2009年提出「資訊安全確保架構」,以ISO 27001/2與BS25999標準、及最佳實務運作原則為參考基準,參考之依據主要是與雲端運算服務提供者及受委託第三方(Third party outsourcers)有關之控制項。其後也會再參考其他的標準如SP800-53,試圖提出更完善的資訊安全確保架構。 值得注意的是,其對於雲端服務提供者與使用者之間的法律上的責任分配(Division of Liability)有詳細說明:在資訊內容合法性部分,尤其是在資訊內容有無取得合法授權,應由載入或輸入資訊的使用者全權負責;而雲端服務提供者得依法律規定主張責任免除。而當法律課與保護特定資訊的義務時,例如個人資料保護相關規範,基本上應由使用者與服務提供者分別對其可得控制部分,進行適當的謹慎性調查(Due Diligence, DD)[4]。 雲端環境中服務提供者與使用者雙方得以實質掌握的資訊層,則決定了各自應負責的範圍與界限。 在IaaS(Infrastructure as a Service)模式中,就雲端環境中服務提供者與使用者雙方應負責之項目,服務提供者無從知悉在使用者虛擬實體(Virtual Instance)中運作的應用程式(Application)。應用程式、平台及在服務提供者基礎架構上的虛擬伺服器,概由使用者所完全主控,因此使用者必須負責保護所佈署的應用程式之安全性。實務上的情形則多由服務提供者協助或指導關於資訊安全保護的方式與步驟[5]。 在PaaS(Platform as a Service)模式中,通常由雲端服務提供者負責平台軟體層(Platform Software Stack)的資訊安全,相對而言,便使得使用者難以知悉其所採行的資訊安全措施。 在SaaS(Software as a Service)模式中,雲端服務提供者所能掌控的資訊層已包含至提供予使用者所使用的應用程式(Entire Suite of Application),因此該等應用程式之資訊安全通常由服務提供者所負責。此時,使用者應瞭解服務提供者提供哪些管理控制功能、存取權限,且該存取權限控制有無客製化的選項。 二、CSA「雲端資訊安全控制架構」[6] CSA於2010年提出「雲端資訊安全控制架構」(Cloud Controls Matrix, CCM),目的在於指導服務提供者關於資訊安全的基礎原則、同時讓使用者可以有評估服務提供者整體資訊安全風險的依循。此「雲端資訊安全控制架構」,係依循CSA另一份指引「雲端運算關鍵領域指引第二版」[7]中的十三個領域(Domain)而來,著重於雲端運算架構本身、雲端環境中之治理、雲端環境中之操作。另外CCM亦將其控制項與其他與特定產業相關的資訊安全要求加以對照,例如COBIT與PCI DSS等資訊安全標準[8]。在雲端運算之國際標準尚未正式出爐之前,CSA提出的CCM,十分完整而具備豐富的參考價值。 舉例而言,資訊治理(Data Governance)控制目標中,就資訊之委託關係(Stewardship),即要求應由雲端服務提供者來確認其委託的責任與形式。在回復力(Resiliency)控制目標中,要求服務提供者與使用者雙方皆應備置管理計畫(Management Program),應有與業務繼續性與災害復原相關的政策、方法與流程,以將損害發生所造成的危害控制在可接受的範圍內,且回復力管理計畫亦應使相關的組織知悉,以使能在事故發生時即時因應。 三、日本經產省「運用雲端服務之資訊安全管理指導原則」[9] 日本經濟產業省於2011年提出「運用雲端服務之資訊安全管理指導原則」,此指導原則之目的是期待藉由資訊安全管理以及資訊安全監督,來強化服務提供者與使用者間的信賴關係。本指導原則的適用範圍,主要是針對機關、組織內部核心資訊資產而委託由外部雲端服務提供者進行處理或管理之情形,其資訊安全的管理議題;其指導原則之依據是以JISQ27002(日本的國家標準)作為基礎,再就雲端運算的特性設想出最理想的資訊環境、責任配置等。 舉例而言,在JISQ27002中關於資訊備份(Backup)之規定,為資訊以及軟體(Software)應遵循ㄧ定的備份方針,並能定期取得與進行演練;意即備份之目的在於讓重要的資料與軟體,能在災害或設備故障發生之後確實復原,因此應有適當可資備份之設施,並應考量將備份措施與程度的明確化、備份範圍與頻率能符合組織對於業務繼續性的需求、且對於儲存備份資料之儲存媒體亦應有妥善的管理措施、並應定期實施演練以確認復原程序之有效與效率。對照於雲端運算環境,使用者應主動確認雲端環境中所處理之資訊、軟體或軟體設定其備份的必要性;而雲端服務提供者亦應提供使用者關於備份方法的相關訊息[10]。 参、針對雲端運算之認證與登錄機制 一、CSA雲端安全知識認證 CSA所推出的「雲端安全知識認證」(Certificate of Cloud Security Knowledge, CCSK),是全球第一張雲端安全知識認證,用以表示通過測驗的人員對於雲端運算具備特定領域的知識,並不代表該人員通過專業資格驗證(Accreditation);此認證不能用來代替其他與資訊安全稽核或治理領域的相關認證[11]。CSA與歐盟ENISA合作進行此認證機制的發展,因此認證主要的測試內容是依據CSA的「CSA雲端運算關鍵領域指引2.1版(英文版)」與ENISA「雲端運算優勢、風險與資訊安全建議」這兩份文件。此兩份文件採用較為概略的觀念指導方式,供讀者得以認知如何評估雲端運算可能產生的資訊安全風險,並採取可能的因應措施。 二、CSA雲端安全登錄機制 由CSA所推出的「雲端安全登錄」機制(CSA Security, Trust & Assurance Registry, STAR),設置一開放網站平台,採取鼓勵雲端服務提供者自主自願登錄的方式,就其提供雲端服務之資訊安全措施進行自我評估(Self Assessment),並宣示已遵循CSA的最佳實務(Best Practices);登錄的雲端服務提供者可透過下述兩種方式提出報告,以表示其遵循狀態。 (一)認知評價計畫(Consensus Assessments Initiative)[12]:此計畫以產業實務可接受的方式模擬使用者可能之提問,再由服務提供者針對這些模擬提問來回答(提問內容在IaaS、PaaS與SaaS服務模式中有所不同),藉此,由服務提供者完整揭示使用者所關心的資訊安全議題。 (二)雲端資訊安全控制架構(CCM):由服務提供者依循CCM的資訊安全控制項目及其指導,實踐相關的政策、措施或程序,再揭示其遵循報告。 資安事故的確實可能使政府機關蒙受莫大損失,美國南卡羅萊納州稅務局(South Carolina Department of Revenue)2012年發生駭客攻擊事件,州政府花費約2000萬美元收拾殘局,其中1200萬美元用來作為市民身份被竊後的信用活動監控,其他則用來發送被害通知、資安強化措施、及建立數位鑑識團隊、資安顧問。 另一方面,使用者也可以到此平台審閱服務提供者的資訊安全措施,促進使用者實施謹慎性調查(Due Diligence)的便利性並累積較好的採購經驗。 三、日本-安全・信頼性資訊開示認定制度 由日本一般財團法人多媒體振興協會(一般財団法人マルチメディア振興センター)所建置的資訊公開驗證制度[13](安全・信頼性に係る情報開示認定制度),提出一套有關服務提供者從事雲端服務應公開之資訊的標準,要求有意申請驗證的業者需依標準揭示特定項目資訊,並由認證機關審查其揭示資訊真偽與否,若審查結果通過,將發予「證書」與「驗證標章」。 此機制始於2008年,主要針對ASP與SaaS業者,至2012年8月已擴大實施至IaaS業者、PaaS業者與資料中心業者。 肆、雲端運算資訊安全國際標準之形成 現國際標準化組織(International Organization for Standardization, ISO)目前正研擬有關雲端運算領域的資訊安全標準。ISO/IEC 27017(草案)[14]係針對雲端運算之資訊安全要素的指導規範,而ISO/IEC 27018(草案)[15]則特別針對雲端運算的隱私議題,尤其是個人資料保護;兩者皆根基於ISO/IEC 27002的標準之上,再依據雲端運算的特色加入相應的控制目標(Control Objectives)。 [1]http://www.ntpc.gov.tw/web/News?command=showDetail&postId=277657 (最後瀏覽日:2013/11/20) [2]European Network and Information Security Agency [ENISA], Cloud Computing: Benefits, Risks and Recommendations for Information Security 53-59 (2009). [3]ENISA, Cloud Computing-Information Assurance Framework (2009), available at http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-information-assurance-framework . [4]ENISA, Cloud Computing-Information Assurance Framework 7-8 (2009). [5]ENISA, Cloud Computing-Information Assurance Framework 10 (2009). [6]CSA, Cloud Controls Matrix (2011), https://cloudsecurityalliance.org/research/ccm/ (last visited Nov. 20, 2013). [7]CSA, CSA Guidance For Critical Areas of Focus in Cloud Computing v2 (2009), available at https://cloudsecurityalliance.org/research/security-guidance/#_v2. (last visited Nov. 20, 2013). [8]https://cloudsecurityalliance.org/research/ccm/ (last visited Nov. 20, 2013). [9]日本経済産業省,クラウドサービスの利用のための情報セキュリティマネジメントガイドライン(2011),http://www.meti.go.jp/press/2011/04/20110401001/20110401001.html,(最後瀏覽日:2013/11/20)。 [10]日本経済産業省,〈クラウドサービスの利用のための情報セキュリティマネジメントガイドライン〉,頁36(2011)年。 [11]https://cloudsecurityalliance.org/education/ccsk/faq/(最後瀏覽日:2013/11/20)。 [12]https://cloudsecurityalliance.org/research/cai/ (最後瀏覽日:2013/11/20)。 [13]http://www.fmmc.or.jp/asp-nintei/index.html (最後瀏覽日:2013/11/20)。 [14]Information technology - Security techniques- Security in cloud computing (DRAFT), http://www.iso27001security.com/html/27017.html (last visited Nov. 20, 2013). [15]ISO/IEC 27018- Information technology -Security techniques -Code of practice for data protection, controls for public cloud computing services (DRAFT), http://www.iso27001security.com/html/27018.html (last visited Nov. 20, 2013).