評估保障等級

評估保障等級（Evaluation Assurance Level）簡稱EAL，是用數字級別說明產品依資訊技術安全評估共同準則（Common Criteria）評估的程度，從EAL1到EAL7。數字級別越高，評估時的嚴謹程度就越高，需要的佐證資料也越多，對於系統主要安全功能實施的信心程度也越高。EAL等級不會測量系統的安全性，只會說明系統要如何驗證到什麼程度。

若電腦系統要達到特定的評估保障等級，系統需要符合特定的保障需求（assurance requirements）。大部份的保障需求會和設計文件、設計分析、功能測試或滲透測試有關。若評估保障等級越高，表示文件、分析或是測試會更加的深入。一般而言，要達到較高評估保障等級，所花的金錢以及時間都會比較低的評估保障等級要多。若要求系統達到某評估保障等級，表示此系統滿足該評估保障等級中的所有需求。

就算所有產品及系統都符合同一個保障需求，達到相同的一個評估保障等級，但這些產品的功能需求可能會不同。在產品進行評估時，會將認證產品的功能列在安全目標（Security Target，ST）文件中。因此，評估保障等級較高的產品，安全程度不一定高於等級較低的產品，還是要視二個產品的安全目標而定。產品是否符合特定的安全應用，要看產品安全目標中的功能是否滿足該應用的安全需求。若二個產品的安全目標都可以滿足需求，評估保障等級較高的產品會比較值得信賴。

保障等級

EAL1：功能檢測（Functionally Tested）

EAL1需確認產品的功能正常，有證據以佐證系統可以正常運作，適用於安全威脅不嚴重的情形。若需要獨立的保證來確定，系統會針對個人資訊或是類似資訊進行適當保護，可以使用EAL1。

EAL1會是使用者可以進行，針對評估目標（TOE）的評估，包括對某規格的獨立測試，並且檢查所提供的指引文件。EAL1設計的目的是要EAL1的評估可以在沒有評估目標開發者的協助下進行，且用最少的成本進行。此一層級的評估可以佐證評估目標的功能和其文件一致，且針對已識別到（且寫在文件中）的威脅，可以提供有效的保護。

EAL2：結構檢測（Structurally Tested）

EAL2需要開發者提供設計資訊及測試結果，不過其付出心力和一般良好商業實務下的開發者相當。開發者應該不會因為EAL2而大幅增加成本，或是延長開發時間。EAL2適用於設計者或是使用者需要低度到中度的獨立性安全保證，但還沒有完整開發記錄的情形。在為舊系統提昇安全性時，常會遇到此一情形。

EAL3：系統測試及檢查（Methodically Tested and Checked）

EAL3讓嚴謹的開發者在開發階段時，就以最積極的安全工程作法，盡全力保證產品安全，因此開發者會嚴格檢查程式碼，但針對已有的良好開發流程，不需作更動。EAL3適用於設計者或是使用者需要中度的獨立性安全保證，並且對評估目標以及開發進行徹底的檢視，但不打算大量修改的情形。

EAL4：系統設計、測試及審查（Methodically Designed, Tested and Reviewed）

EAL4讓嚴謹的開發者在開發階段時，就以最積極的安全工程作法，配合良好的商業實務，盡全力保證產品安全，過程嚴謹，但開發者不需特殊的知識、技術或是其他資源。若是在現有的產品線進行改造，EAL4是經濟上可行的最高級別。EAL4適用於傳統開發方式的評估目標，開發者或是用戶需要中度或高度的獨立保證安全性，且可以接受額外的安全相關工程成本的情形。

提供以使用者為基礎，傳統安全性的商業作業系統常會用EAL4來評估。以下是一些曾用EAL4評估，已過期的例子：例如IBM AIX[1]、HP-UX[1]、Oracle Linux、 NetWare、Solaris[1]、SUSE Linux Enterprise Server 9, 10[1][2][3]、Red Hat Enterprise Linux 5[4][5]、 Windows 2000 Service Pack 3、Windows 2003[1][6]、Windows XP[1][6]、Windows Vista[7][8]、 Windows 7[1][9]、Windows Server 2008 R2,[1][9] z/OS 2.1版[1]。

有多级别安全的作業系統至少會以EAL4來評估。目前認證還有效的有 SUSE Linux Enterprise Server 15（EAL 4+）[10]。曾有認證，但已過期的有Trusted Solaris、Solaris 10 Release 11/06 Trusted Extensions[11]、XTS-400的早期版本、VMware ESXi4.1版[12]、3.5版、4.0版、AIX 4.3、AIX 5L、AIX 6, AIX7、Red Hat 6.2及SUSE Linux Enterprise Server 11（EAL 4+）。

EAL5：半形式設計和測試（Semiformally Designed and Tested）

EAL5讓開發者透過安全工程盡全力保證產品安全，安全工程是以嚴謹商業開發實務為其基礎，並且應用專門的安全工程技術。這類的評估目標一般就是以達到EAL5保證為目的來進行設計和開發的。很可能EAL5需求的額外成本，相較於沒有應用此特定技術的嚴謹開發流程來說，成本不算太高。EAL5適用於開發者或是使用者需要在已規劃好的開發上，有高度獨立確保的安全性，而且需要嚴謹開發流程，不會產生不合理成本的特殊安全工程技術。

許多智慧卡的設備是以EAL5來評估，有些多層次安全設備也是如此，例如Tenix的Interactive Link。XTS-400（STOP 6）是多功能的作業系統，評估為EAL5+。

IBM Z的LPAR也是以EAL5來評估[13]。

EAL6：半形式驗證設計和測試（Semiformally Verified Design and Tested）

EAL6是以讓高價值資產避免特定風險為目的，讓開發者在嚴謹開發環境下，應用專門的安全工程技術，開發高度安全保證的優質評估目標。因此，EAL6適用於開發應用在高風險情境下的安全評估目標，其要保護資產的價值超過所增加的開發成本。

Green Hills軟體的INTEGRITY-178B實時作業系統，是屬於EAL6+的等級[1]。

EAL7：形式驗證設計和測試（Formally Verified Design and Tested）

EAL7適用於開發在高風險情境下的安全評估目標，且保護資產的價值會高過其開發成本的情形，是最高等級的保障等級。

EAL7的實際應用目前只在高度強調安全功能的評估目標，且安全功能很容易進行廣泛形式分析的應用。Tenix Interactive Link的Data Diode Device產品，以及Fox-IT的Fox Data Diode產品（單向資料通訊設備）聲稱有依EAL7的加強版（EAL7+ ）[14]。

保障等級的意涵

以技術層面來說，較高等級的EAL意味著其評估過程滿足了更嚴謹的品質保證要求。一般會假設達到更高EAL等級的系統，其安全機能會更可靠（因此所需的第三方分析以及安全專家進行的測試是這個方向的合理依據），不過可支持此假設的證據還不多。

對成本和時程的影響

美國政府問責署在2006年發表了有關資訊技術安全評估共同準則評估的報告，總結了一系統從EAL2到EAL4專案的成本以及時程。EAL2的時程約在4到10個月不等，EAL4的時程從9到24個月不等。

在1990年代中期到末期，供應商在相當於EAL4的評估，約花費100萬到250萬美元的費用，有關Microsoft Windows安全評估的費用，還沒有對應的報告可以佐證。

EAL要求的增強版

有些情形下的評估，除了特定EAL的最低需求外，還會加入額外的保證需求。正式的標示方式會在EAL的數字後面加上augmented，並且加上新增需求的代號列表。若用縮寫表示，供應商一般會用加號表示有增加的需求（如EAL4+）。

EAL標示方式

在資訊技術安全評估共同準則中有提到標示EAL的方式：在EAL後直接加上1到7的數字，不用空格隔開（例如EAL1、EAL3、EAL5）。實務上，有些國家會在EAL和數字中間加上空格（EAL 1、EAL 3、EAL 5)。數字後面的加號是供應商標示有增加需求的非正式作法（EAL4+或EAL 4+）。

參考資料
  1. . [2008-04-28]. （原始内容存档于2013-12-31）.
  2. (PDF). [2008-04-28]. （原始内容 (PDF)存档于2015-09-23）.
  3. . [2008-04-28]. （原始内容存档于2008-05-22）.
  4. . [2007-06-16]. （原始内容存档于2007-06-19）.
  5. . [2023-10-26]. （原始内容存档于2012-07-07）.
  6. Windows Platform Products Awarded Common Criteria EAL 4 Certification 的存檔，存档日期2006-04-20.
  7. Myers, Tim. . Microsoft. [May 15, 2013]. （原始内容存档于2013-11-11）.
  8. (PDF). [May 15, 2013]. （原始内容 (PDF)存档于March 27, 2014）.
  9. . [2023-10-26]. （原始内容存档于2017-08-26）.
  10. (PDF). Common Criteria Portal. [9 September 2022]. （原始内容存档 (PDF)于2023-12-26）.
  11. (PDF). [2023-10-27]. （原始内容存档 (PDF)于2023-10-27）.
  12. . [2019-01-27]. （原始内容存档于2020-01-28）.
  13. IBM System z Security （页面存档备份，存于）; IBM System z partitioning achieves highest certification （页面存档备份，存于）
  14. . （原始内容存档于2020-09-23）.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.