クラウドやコンテナのセキュリティ評価でも使われている「Compliance As Code」の始め方：OpenSCAPで脆弱性対策はどう変わる？（終）
本連載では、グローバルスタンダードになっている「SCAP」（セキュリティ設定共通化手順）およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、OpenSCAP／SCAP Security Guideプロジェクトの発展形である「Compliance As Code」について実例を見ながら解説する。
OSSセキュリティ技術の会の面和毅です。本連載「OpenSCAPで脆弱（ぜいじゃく）性対策はどう変わる？」では、実質的にグローバルスタンダードの「SCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）」、およびそれを基にシステム構成や脆弱性の検査を行うためのOSS（オープンソースソフトウェア）ツール「OpenSCAP」や、その周辺の技術、用語などを紹介してきました。
今回は最終回。コミュニティーベースでのOpenSCAP、SCAP Security Guide Projectの発展形である「Compliance As Code」（旧SCAP Security Guide）について、実例を見ながら解説します。
Compliance As Codeのプロジェクトと詳細は、こちらのGitHubから確認できます。
Compliance As Codeのコンテンツをソースからコンパイルする
前回説明した通り、Compliance As CodeのコンテンツはZIPファイルで定期的に出されていますが、より最新のコンテンツを利用したいときや、細かいバグ修正などが施されているものを利用したいときには、ソースコードからコンパイルした方が便利です。
以下で、GitHubで提供されているコンテンツのソースコードのコンパイルと利用方法を説明します。
Compliance As Codeのcontentのコードは、こちらのGitHubからダウンロードできます。ソースコードの中身ですが、図1のようにOSやアプリケーションなど製品ごとにディレクトリが分かれた構造になっています。
コンテンツをソースコードからコンパイルする方法ですが、「Compliance As Code Developer Guide」に方法が書いてあるので、こちらに従うと簡単に行えます。今回はDebian 10（buster）を使うのでDebianの方法に従います。
1.cmake/makeやpython3-yamlなどのコンパイルに必要なパッケージをインストールします。
apt-get install cmake make expat libopenscap8 libxml2-utils ninja-build python3-jinja2 python3-yaml xsltproc
2.Gitでcontentのソースコードをローカルにクロ−ンします。
git clone https://github.com/Compliance As Code/content.git
以下、content/buildディレクトリで作業します。
3.content/buildディレクトリで「cmake ..」としてcmakeを実行し、buildファイルを作成します（図2）。
jsosug@localhost:~/ComplianceAsCode/content/build$ cmake .. -- SCAP Security Guide 0.1.52 -- SCAP Security Guide 0.1.52 -- CMake: -- build type: Release -- generator: Unix Makefiles ---省略--- -- Scanning for dependencies of sle15 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of ubuntu1404 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of ubuntu1604 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of ubuntu1804 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of vsel fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of wrlinux8 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Scanning for dependencies of wrlinux1019 fixes (bash, ansible, puppet, anaconda, ignition and kubernetes)... -- Configuring done -- Generating done -- Build files have been written to: /home/jsosug/ComplianceAsCode/content/build
4.ビルドしたい製品を選んでmakeを行います。今回は、Debian 10のコンテンツをコンパイルしたいので、「make -j4 debian10」とします（図3）。
jsosug@localhost:~/ComplianceAsCode/content/build$ make -j4 debian10 make[1]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' に入ります make[2]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' に入ります make[3]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' に入ります Scanning dependencies of target generate-internal-bash-remediation-functions.xml [100%] Built target debian10-tables make[3]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' に入ります Scanning dependencies of target debian10 make[3]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' から出ます [100%] Built target debian10 make[2]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' から出ます make[1]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' から出ます
5.buildディレクトリに「ssg-debian10-ds.xml」などのスキャンに使用するデータストリームファイルが生成されます（図4）。
6.build/guidesディレクトリに、それぞれ生成されたコンテンツの説明があるので、「ssg-debian10-guide-index.html」ファイルをブラウザで見てみます。コンテンツのプロファイルごとに選べて、それぞれのチェックリスト項目の説明が記載されています。また、右上にはoscapコマンドを用いて実行する際のサンプルコマンドが記載されています（図5）（図6）。
7.build/ansibleディレクトリに、AnsibleのPlaybookが生成されます（図7）。
ソースコード内容の確認
前章ではコンパイルの方法から確認しましたが、ここではCompliance As Codeのソースコード内にあるディレクトリやファイルを見ていきます。
ディレクトリ構造、ファイル構造
まずcontent以下のディレクトリ構造ですが、ディレクトリの内容とそれぞれの説明は表1のようになっています。
| ディレクトリ名 | 説明 |
|---|---|
| linux_os | Linux用の必要なセキュリティコンテンツが入っている。rule、OVALチェック、Ansibleタスク、Bashによる修正など |
| applications | OpenShiftやOpenStackなどのアプリケーション用セキュリティコンテンツが入っている。rule、OVALチェック、Ansibleタスク、Bashによる修正など |
| shared | JinjaマクロやBashの修正関数を生成するためのテンプレートが入っている |
| tests | コンテンツの確認とテストのためのテストスイートとunitテストが入っている |
| build | CMakeを用いたコンテンツのビルドに使用される |
| build-scripts | ビルドシステムで使用されるスクリプト |
| cmake | CMakeのビルド設定ファイルが入っている |
| Dockerfiles | コンテナバックエンドのビルドコンテンツとテストスイートが入っている |
| docs | ユーザーガイドとデベロッパーガイド、マニュアルページ、テンプレートなどが入っている |
| ssg | このリポジトリのほとんどのスクリプトで使用される、Pythonのssgモジュールが入っている |
| utils | システムビルドには使用しないが開発で使用されるような、さまざまなスクリプトが入っている。FedoraやRHEL（Red Hat Enterprise Linux）7など、プロダクトのディレクトリ |
また、ファイル類は表2のようになっています。
| ファイル名 | 説明 |
|---|---|
| CMakeLists.txt | CMakeビルド設定ファイル |
| Contributors.md | DO NOT MANUALLY EDIT スクリプトにより生成されるファイル |
| Contributors.xml | DO NOT MANUALLY EDIT スクリプトにより生成されるファイル |
| DISCLAIMER | コンテンツ使用に関する免責事項 |
| LICENSE | コンテンツのライセンス |
| README.md | README ファイル |
また、ディレクトリとして定義されているプロダクトの名前や構造には、後のデバッグなどをやりやすくするために、以下のようなガイドライン（マナー）があります。
- 大文字を使わないようにする
- プロダクトバージョンが必要な際には、メジャーバージョンのみを使う。例えば、RHEL 7、Ubuntu 16など
- 生成するコンテンツがバージョンに依存しない場合には、バージョン番号を付けない。例えば、Fedora、Firefoxなど
- 加えて、ディレクトリの最大深度は3になるようにする。
これらのディレクトリの中に、種々の定義ファイルなどが入っていて、makeコマンドを実行すると「ssg-｛プロダクト名｝-ds.xml」などが生成されます。
ベンチマークとグループ、ルール
次にベンチマークの種類とディレクトリですが、表3のようになっています。
| ベンチマークの種類 | rootディレクトリ |
|---|---|
| Linux | /linux_os/guide |
| Applications | /applications |
| Java Runtime Environment | /jre/guide |
| Fuse 6 | /fuse6/guide |
| JBoss Enterprise Application Platform（EAP）6 | /eap6/guide |
| Firefox | /firefox/guide |
| Chromium | /chromium/guide |
例えばLinuxに関しての一般的なベンチマークは、linux_os/guide以下にあります。このベンチマークがFedoraやRHEL、Debianなどで使われます。
プロダクトはそれぞれ「どのベンチマークを使用しているか」が「contents/｛プロダクト名｝/product.yml」ファイルに「benchmark_root」としてrootディレクトリへの相対パスで記されています。例えば、RHEL 8の場合には、図8のようにbenchmark_rootは「../linux_os/guide」となっています。
それぞれのベンチマークはディレクトリ構造になっていて、グループでまとめられたルールの集合になっています。グループディレクトリにはgroup.ymlファイル、ルールディレクトリにはrule.ymlファイルが含まれています。例えば、Linuxベンチマークは図9のように構成されています。
linux_os/guide以下で大きく下記のように分かれており、その下に各グループやルールが含まれています。
- intro：Introduction, ドキュメントなど
- services：各種サービス類（ApacheやDHCPなど）
- system：システムの確認（アカウントの設定やパスワードなど）
また、各ルールには使用できるプロダクトが定義されており、ルールごとに「rules.yml」ファイル内に「prodtype」として定義されています。デフォルト（特に記述がない場合）は全てのプラットフォームがそのルールを使用できます。「prodtype」として指定してある場合には、列挙してあるプロダクト以外は該当ルールを使えません。
RHEL 8用のサンプルを見てみる
これらベンチマーク内のルールは、プロダクトの各プロファイルから呼び出されて「サービスがどのユーザーで起動しているか」「パスワード長がきちんとそれぞれのプロファイルの要件に合っているかどうか」などを確認できます。
例えば、プロダクトのサンプルとしてRHEL 8を見てみましょう。RHEL 8はcontents/rhel8以下で定義されています。使用されているルールは、「contents/｛プロダクト名｝/profiles/｛プロファイル名｝」内で「selections」として定義されています（図10）。
このselections内の「accounts_password_set_min_life_existing」は、「linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_set_min_life_existing」ディレクトリとして作成されており、ルールファイルは「rule.yml」です。rule.ymlファイルを見てみると、図11のように「prodtype」でRHEL 8がこのルールを使用できるようになっています。
exapmle productでコンテンツを生成して確認する
Compliance As Codeのコンテンツ作成の作法を理解するために、提供されている「example」のプロダクトをコンパイルしてみましょう。
exampleのプロダクトをコンパイルする
exampleを使えるようにするには、先述のcmakeに「-DSSG_PRODUCT_EXAMPLE=ON」オプションを付けてCMakeを実行します。その後、「make example」で、exampleのプロダクト用のデータストリームやXCCDFファイルが生成されます（図12）。
jsosug@localhost:~/ComplianceAsCode/content/build$ cmake -DSSG_PRODUCT_EXAMPLE=ON ../ -- Setting build type to 'Release' as none was specified. -- SCAP Security Guide 0.1.52 --省略-- -- Generating done -- Build files have been written to: /home/jsosug/ComplianceAsCode/content/build jsosug@localhost:~/ComplianceAsCode/content/build$ make -j4 example make[1]: ディレクトリ '/home/jsosug/ComplianceAsCode/content/build' に入ります --省略-- jsosug@localhost:~/ComplianceAsCode/content/build$ ls CMakeCache.txt fuse6 sle15 CMakeFiles guides ssg-example-cpe-dictionary.xml CPackConfig.cmake jinja2_cache ssg-example-cpe-oval.xml CPackSourceConfig.cmake jre ssg-example-ds-1.2.xml CTestTestfile.cmake macos1015 ssg-example-ds.xml Makefile ocp3 ssg-example-ocil.xml ansible ocp4 ssg-example-oval.xml bash ol7 ssg-example-xccdf-1.2.xml bash-remediation-functions.xml ol8 ssg-example-xccdf.xml build_config.yml opensuse tables chromium rhcos4 tests cmake_install.cmake rhel6 ubuntu1404 debian10 rhel7 ubuntu1604 debian8 rhel8 ubuntu1804 debian9 rhosp10 vsel eap6 rhosp13 wrlinux1019 example rhv4 wrlinux8 fedora sle11 firefox sle12
exampleの生成物を用いてスキャンしてみる
前述のmake exampleで生成されたexampleプロダクト用のデータストリームのうち、「ssg-example-ds.xml」ファイルを使ってみます。
適当なFedora 32上でscap-workbenchを実行し、「ssg-example-ds.xml」ファイルを読み込ませた結果が図13です。
当然ながら、Fedora用に変更していない状態（example OS用）なので、ほぼスキャンは動作しませんが、scap-workbench上で取り扱えるデータ形式となって出力されていることが分かると思います。
後は、個別のOS用に修正のmake exampleを繰り返していけば、望むOS用のデータストリームを生成できます。
終わりに
今回はCompliance As Codeについて、ソースコードを修正するなどして利用していく方法を見ていきました。今回でOpenSCAPやCompliance As Codeに関する一通りの説明は終わります。
SCAPはセキュリティ設定の共通化手順として一般的に利用されています。それを利用したOpenSCAPやCompliance As Codeの成果物は、クラウドやコンテナなどでセキュリティを評価するツールとして広く使われています。本連載がSCAPやSCAPを利用したOSSプロジェクトへの興味のきっかけとなり、さらにOSSプロジェクトへのコントリビュートが増えれば、筆者としてはうれしい限りです。
筆者紹介
面和毅
略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログ、Red Hatブログを連載中。
CISSP：#366942
近著：『Linuxセキュリティ標準教科書』（LPI-Japan）
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
2017年の脆弱性報告件数は過去最高の約1万4700件、まだ隠れた脆弱性がある可能性も：ESET
ESETによると、2017年は脆弱性の報告件数が前年比で2倍以上に増えて過去最高となり、中でも重大な脆弱性が近年の傾向に沿って急激に増加した。
外注したシステムの脆弱性は誰のせい？ 連日の「深刻な脆弱性」にどう向き合い、どう対応するか？
連日のように公開される脆弱性情報の中から自分たちに関係するものを見つけ、適切な優先順位で対応するのは容易ではない。この状況に、企業はどう向き合えばよいのだろうか？ ＠ITは、2017年8月30日にセミナー『連日の「深刻な脆弱性」どう向き合い、どう対応するか』を東京で開催した。多数の専門家やセキュリティベンダーが登壇した同セミナーの模様をお届けしよう。
「脆弱性情報」をどう扱うか――見つける人、流通させる人、対処する人、それぞれの視点
連日公表されるソフトウェアなどの脆弱（ぜいじゃく）性情報。2016年12月1日に行われた「Internet Week 2016」では、「脆弱性情報と賢く付き合う〜発見から対策までの最前線〜」と題したプログラムが開催された。