「Compliance As Code」とは――Ansible Playbookと組み合わせてみよう：OpenSCAPで脆弱性対策はどう変わる？（8）

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

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

　OSSセキュリティ技術の会の面和毅です。本連載「OpenSCAPで脆弱（ぜいじゃく）性対策はどう変わる？」では、実質的にグローバルスタンダードの「SCAP（Security Content Automation Protocol：セキュリティ設定共通化手順）」、およびそれを基にシステム構成や脆弱性の検査を行うためのOSS（オープンソースソフトウェア）ツール「OpenSCAP」や、その周辺の技術、用語などを紹介しています。

　今回と次回で、コミュニティーベースでのOpenSCAP／SCAP Security Guideプロジェクトの発展形である「Compliance As Code」の状況を、実例とともに見ていきたいと思います。

Compliance As Codeとは

　「SCAP Security Guide」（SSG）は、2011年から米国の政府系機関と商用のOSベンダーの間で開始されたプロジェクトです。SSGはもともと、おのおののOSが「（軍などの）政府系の規格を満たしているか」を確認するXCCDF（eXtensible Configuration Checklist Description Format：セキュリティ設定チェックリスト記述形式）ファイルを作ることが目的だったのです。この取り組みがさらに発展して、OSSとしてツールも開発され、扱われる規格も政府系のもののみならず、PCI DSSなどの商用系のものも含まれるようになりました。

　さらに2017年ごろから、一般的な企業でも「Ansible」「Chef」「Puppet」などが構成管理／設定ツールとして使用されることになったため、SSGはより一般的なセキュリティコンテンツをターゲットとして、このような構成管理・設定ツールと連動して動くようなものに発展させることになりました。

　結果として、2018年9月から、SSGプロジェクトは「Compliance As Code」というふうにプロジェクト名を変えることになりました。

　Compliance As Codeと名前を変えてからは、「oscap」などの（低レベルで動く）ツールも使用しつつ、XCCDFなどが分からないユーザーでも、セキュリティコンテンツを簡単に理解して自サーバに適用できるように、GUIツールやAnsibleを経由して抽象化された形に取り組んでいます。

　Compliance As Codeのプロジェクトと詳細は、こちらのGitHubから理解することができます。

Compliance As Codeを試してみる

　まずはCompliance As Codeを理解するために、コンテンツをダウンロードして実行してみましょう。

　主なディストリビューションでも「apt」「dnf」でインストールできますが、より最新のバージョンを使用したい場合にはプロジェクトの成果物を直接使用した方がいいでしょう（さらに多くのOS／環境に対応したバージョンが取得できます）。

　コンテンツなどがビルド済みのZIPファイルか、ソースコード全てをダウンロードするかを選ぶ必要があります。

　ソースコードとビルド済みコンテンツなどの関係は図1を参照してください。

図1

　次回、ソースコードをダウンロードして中を見るので、今回はZIPによるビルド済みのものを入手して使いましょう。

ビルド済みのZIPをダウンロードする

　ビルド済みのZIPは、GitHubのこちらのページから入手できます。定期的にバージョンを付けてリリースされています（2020年7月10日現在の最新バージョンは0.1.50です）。

　展開すると図2のように、oscapコマンドや「SCAP-Workbench」で使えるデータストリームのXMLファイルが直下にあります。それぞれSCAP 1.2用とSCAP 1.3用のバージョンごとのファイルが用意されています。

図2

　「guides」以下にはセキュリティプロファイルのガイド、「ansible/bash」ディレクトリにはそのセキュリティプロファイルガイドに従ってOSを設定するためのAnsible Playbookやシェルスクリプトが入っています（なお、bashはAnsibleが使えない環境で使用するものです。使用できる環境であればAnsible Playbookを使用するのがお勧めです）。

セキュリティガイドをSCAP Workbenchを用いて確認する

　guidesディレクトリ以下に、セキュリティプロファイルのガイド（HTML）が入っています。

　例えば、図3は「Debian 10（buster）」の一般的なセキュリティ設定に関するガイド（Standard System Security Profile）です。

図3

　米国立標準技術研究所（NIST）や米国防総省（DoD）などで示されている規約のルールとともに、設定方法もDebianに合わせて記載されています（図4）。

図4

　DVDからインストールしたばかりのリモートのDebian 10に対して、上述の「Standard System Security Profile」を満たしているかどうかのスキャンを実行してみましょう。ここではまず、「CentOS 7」上のGUIツール「SCAP Workbench」を使うことにします。

1．リモート（IP: 172.16.148.160）のDebian 10内でスキャンを実施する際には、リモートのDebian 10内のoscapコマンドを使用するため、oscapコマンドを含む「libopenscap8」パッケージをあらかじめリモートのDebian 10内にインストールしておきます。

2．CentOS 7上でSCAP Workbenchを起動し、Debian 10用のSCAP 1.3データストリーム（ssg-debian10-ds.xml）を読み込ませ、プロファイル「Standard System Security Profile」を選択します（図5）。

図5

3．SCAP Workbenchツール内で「Remote Machine」を選択し、「User and host」の項目に「ユーザーID@ホスト名（IP）」形式でリモートのDebian 10上のユーザーとホストを入力します（図6）。

図6

　この際、また、oscapコマンドを実行するユーザーが十分な権限がないと図7のように「Permission Denied」のエラーとなり、幾つかの特権アクセスが必要となる項目をテストできないため、気を付ける必要があります。

図7

　今回はrootアカウントでsshログインできるようにし、スキャンするようにしています。一般的には、システムの設定が規約にのっとっているかどうかはそう頻繁にチェックするものではないため、チェックを行うときだけの特権アカウントを使用すればいいと思います。

4．スキャンを実行すると、Debian 10上のユーザーのパスワードを聞かれるため、入力します（図8）。

図8

5．スキャンの結果が出力されます（図9）。

図9

6．スキャン結果はHTMLとして保存することも可能です。図10を見ると、要件を満たしていないルールは13であることが分かります。

図10

oscap-sshを用いたリモートのスキャン

　SCAP-Workbenchを用いたGUIツールでのリモートサーバのスキャンは直感的ですが、何十台ものPCを管理している場合には、いちいちGUIツールでスキャンするのは面倒になります。そのような場合には「oscap-ssh」コマンドが手軽です。

　oscap-sshは、bashで書かれたシェルスクリプトで、sshを通じてoscapコマンドをリモート上で実行するものです。スキャンの際のオプションもoscapコマンドとほぼ同じであるため、非常に手軽に使えます。

　また、「sudo」オプションを使うことでリモートのユーザーにsudoを実行させることができます。そのため、リモートスキャン時にsudoで管理者権限を使えるユーザーを設定しておけば、SCAP-Workbenchのような「管理者権限を使用できるユーザーを使わなくては」という懸念を「sudoで管理できるユーザーを使おう」まで低くすることができます。

　「Fedora」やCentOS、「Red Hat Enterprise Linux（RHEL）」の場合、oscap-sshは「openscap-utils」パッケージに同梱されています。Debianに関しては、パッケージとしては用意されていないため、Debianの「UsingSCAP」wikiを参考にし、wgetで「https://raw.githubusercontent.com/OpenSCAP/openscap/maint-1.2/utils/oscap-ssh」自体を落としてきて適当なディレクトリで実行できるようにします。

　今回は先ほどと同様にローカルのCentOS 7上から、リモート（IP：172.16.148.160）のDebian 10に対してoscap-sshコマンドを実行します。

1．SCAP-Workbenchのときと同様に、リモートのDebian 10に関してはoscapコマンドが使えるようにパッケージをインストールしておきます。

2．下記のコマンドで、リモートのDebian 10に「jsosug」ユーザーとして接続し、sudoを実行してスキャンさせます。

[jsosug@localhost ]$ oscap-ssh --sudo jsosug@172.16.148.160 22 xccdf eval --results target-results.xml --report target-report.html --profile xccdf_org.ssgproject.content_profile_standard ~/scap-security-guide-0.1.50/ssg-debian10-ds.xml 

3．oscap-sshを実行すると、まずsshで接続するユーザー（jsosug）のパスワードを聞かれるので入力します。

jsosug@172.16.148.160's password: 

4．ssh接続が終わると、次にsudoのパスワードを聞かれるので入力します。

Starting the evaluation...
[sudo] jsosug のパスワード:

5．下記のようにスキャンが実行されます。

--省略--
Title   Ensure Log Files Are Owned By Appropriate User
Rule    xccdf_org.ssgproject.content_rule_rsyslog_files_ownership
W: oscap:     Obtrusive data from probe!
W: oscap:     Obtrusive data from probe!
Result  pass
--省略--
Title   Install the ntp service
Rule    xccdf_org.ssgproject.content_rule_package_ntp_installed
Result  fail
--省略--

6．図11のように「target-report.html」が生成されます。

図11

Ansible Playbookを用いてシステムを修正する

　先ほど「Compliance As Codeの成果物にはAnsible Playbook、bashスクリプトが同梱されている」と説明しました。これらは、スキャンのプロファイルに合わせた形でシステムを修正するためのものです。Ansibleが使えない環境を加味してbashスクリプトも用意されていますが、Ansibleが使える環境であればAnsibleの方がリモートから簡単にシステムを変更できるため、管理しやすくなっています。

　ここでは、Ansible Playbookを用いて、先ほどのリモートのDebian 10の設定を「Standard System Security Profile」に極力従うように変更します。

1．「ansible」ディレクトリ以下にAnsible Playbook（YAMLファイル）が格納されています。ここではDebian 10の「Standard System Security Profile」に倣って修正するため、「debian10-playbook-standard.yml」を使います。

2．debian10-playbook-standard.ymlを見ると、21行目以下のように使用方法（サンプル）が記載されているのが分かります。

###############################################################################
#
# Ansible Playbook for Standard System Security Profile for Debian 10
#
# Profile Description:
# This profile contains rules to ensure standard security baseline
# of a Debian 10 system. Regardless of your system's workload
# all of these checks should pass.
#
# Profile ID:  standard
# Benchmark ID:  DEBIAN-10
# Benchmark Version:  0.1.50
# XCCDF Version:  1.1
#
# This file was generated by OpenSCAP 1.3.3 using:
# $ oscap xccdf generate fix --profile standard --fix-type ansible xccdf-file.xml
#
# This Ansible Playbook is generated from an OpenSCAP profile without preliminary evaluation.
# It attempts to fix every selected rule, even if the system is already compliant.
#
# How to apply this Ansible Playbook:
# $ ansible-playbook -i "localhost," -c local playbook.yml
# $ ansible-playbook -i "192.168.1.155," playbook.yml
# $ ansible-playbook -i inventory.ini playbook.yml
#
###############################################################################

ansible/debian10-playbook-standard.yml

3．Ansible Playbookのサンプルに従い、下記のコマンドを実行します。

ansible-playbook -i "172.16.148.160," -u jsosug --ask-pass --ask-become-pass debian10-playbook-standard.yml

4．図12のようにリモートのDebian 10の設定が変更されます。

図12

　設定が反映されたかどうかを確認するため、再度oscap-sshコマンドをリモートのDebian 10に実行してみると、図13のようにリモートのDebian 10の設定が変更され、「満たしていないルールセット」の数が13から8に減っていることが分かります。

図13

　Ansible Playbookにより変更できなかった設定を確認すると、「パーティションが分割されていない」など、Ansibleによる設定変更だけではどうしようもない箇所が「満たしていないルールセット」として残されていることが分かります（図14）。

図14

次回は、「Compliance As Code」の使い方

　今回はここまでで、次回はいよいよ最終回です。今回紹介した「Compliance As Code」を、ソースコードを修正するなどして利用する方法を解説します。

筆者紹介

面和毅

略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログ、Red Hatブログを連載中。

CISSP：#366942

近著：『Linuxセキュリティ標準教科書』（LPI-Japan）」