クラウドやコンテナのセキュリティ評価でも使われている「Compliance As Code」の始め方：OpenSCAPで脆弱性対策はどう変わる？（終）

本連載では、グローバルスタンダードになっている「SCAP」（セキュリティ設定共通化手順）およびそれを基にシステム構成や脆弱性の検査を行うためのOSSツール「OpenSCAP」や、その周辺の技術、用語などを紹介する。今回は、OpenSCAP／SCAP Security Guideプロジェクトの発展形である「Compliance As Code」について実例を見ながら解説する。

[面和毅，OSSセキュリティ技術の会]

　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やアプリケーションなど製品ごとにディレクトリが分かれた構造になっています。

図1

　コンテンツをソースコードからコンパイルする方法ですが、「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

図2

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' から出ます

図3

5.buildディレクトリに「ssg-debian10-ds.xml」などのスキャンに使用するデータストリームファイルが生成されます（図4）。

図4

6.build/guidesディレクトリに、それぞれ生成されたコンテンツの説明があるので、「ssg-debian10-guide-index.html」ファイルをブラウザで見てみます。コンテンツのプロファイルごとに選べて、それぞれのチェックリスト項目の説明が記載されています。また、右上にはoscapコマンドを用いて実行する際のサンプルコマンドが記載されています（図5）（図6）。

図5

図6

7.build/ansibleディレクトリに、AnsibleのPlaybookが生成されます（図7）。

図7

ソースコード内容の確認

　前章ではコンパイルの方法から確認しましたが、ここではCompliance As Codeのソースコード内にあるディレクトリやファイルを見ていきます。

ディレクトリ構造、ファイル構造

　まずcontent以下のディレクトリ構造ですが、ディレクトリの内容とそれぞれの説明は表1のようになっています。

表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のようになっています。

表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のようになっています。

表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」となっています。

図8

　それぞれのベンチマークはディレクトリ構造になっていて、グループでまとめられたルールの集合になっています。グループディレクトリにはgroup.ymlファイル、ルールディレクトリにはrule.ymlファイルが含まれています。例えば、Linuxベンチマークは図9のように構成されています。

図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）。

図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がこのルールを使用できるようになっています。

図11

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

図12

exampleの生成物を用いてスキャンしてみる

　前述のmake exampleで生成されたexampleプロダクト用のデータストリームのうち、「ssg-example-ds.xml」ファイルを使ってみます。

　適当なFedora 32上でscap-workbenchを実行し、「ssg-example-ds.xml」ファイルを読み込ませた結果が図13です。

図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）