2017-05-15

May 2017

Volume 32 Number 5

DevOps - InSpec によるコードとしての準拠

Michael Ducy | May 2017

規制への準拠は、あらゆる企業にとって動かし難い現実です。同時に、新たな革新的テクノロジの出現とデジタルサービスに対する顧客の期待によって、競争というプレッシャーがますます高まっています。このような状況でも、業界は規制への準拠という義務を果たしながら、新たな製品やサービスを迅速に提供することは可能なのでしょうか。

答えはイエスです。解決策は、規制への準拠をソフトウェアの製造ラインに組み込むことです。これは、自動車のフレーム強度や銀行業務アプリケーションの応答ラウンドトリップ時間といった品質を製造ラインに組み込むのと同じ考え方です。

規制への準拠をコードとして表現できれば、こうした準拠を配置プロセスの不可欠な部分にすることができます。システムの構成がコードとしてのインフラストラクチャ (PowerShell Desired State Configuration や Chef など) に変わっていくのと同様に、プログラミング言語を使って準拠を管理します。

InSpec はオープンソースプロジェクトで、人間にもコンピューターにも判読できる言語で準拠の要件を定義できるようにします。こうした要件を成文化したら、システムを監査する自動テストとして実行します。InSpec は、ローカルエージェントだけでなく、完全なリモートテストサポートも提供します。

また、Windows から Linux まで、多種多様なプラットフォームをサポートします。図 1 は、比較的人気の高いプラットフォームを示しています (サポート対象プラットフォームの完全な一覧は、InSpec の Web サイト inspec.io (英語) で確認できます)。

図 1 inSpec でサポートされる人気のプラットフォームの一覧

プラットフォーム	バージョン
AIX	6.1、7.1、7.2
Mac OS X	10.9、10.10、10.11
Oracle Enterprise Linux	5、6、7
Red Hat Enterprise Linux (バリアントも含む)	5、6、7
Solaris	10、11
Windows	7、8、8.1、10、2008、2008 R2、2012、2012 R2、2016
Ubuntu Linux
SUSE Linux Enterprise Server	11、12
OpenSUSE	13.1、13.2、42.1
HP-UX	11.31

InSpec の広範なプラットフォームサポートは、InSpec をインフラストラクチャ全体で準拠を管理する場合の完全な解決策にしています。InSpec はオープンソースプロジェクトなので、OS ベンダーの中には自社のプラットフォームのサポートに利用しているベンダーもあります。たとえば、IBM は同社の AIX OS のサポートの大部分に利用しています。

InSpec の使用を開始する

InSpec を使い始めるのは簡単です。InSpec は Chef Development Kit (Chef DK) に含まれています。さまざまなプラットフォーム向けのパッケージを Chef のダウンロード Web サイト (downloads.chef.io/inspec、英語) からダウンロードできます。パッケージをダウンロードしてインストールすれば、準拠の規則の作成を開始できます (準拠規則は、セキュリティチームがよく使いますが、監査統制とも呼ばれています)。

InSpec の規則の作成は、書式を理解してしまえば簡単です。すべての規則はリソースから始まります。リソースとは、テスト対象の構成項目です。たとえば、以下は windows_feature リソースを使用する InSpec 規則です。

describe windows_feature('DHCP Server') do
  it { should_not be_installed }
end

この windows_feature リソースは、Windows 機能の名前を宣言し、特定の構成と一致するかどうかを確認するテストを行います。この例の規則は、DHCP サーバーがインストールされていないことをテストします。

ネットワークの多くの標準要素には、ファイル、ディレクトリ、ユーザー、グループ、レジストリキーなどのリソースがあります。完全な一覧については、InSpec のドキュメント (bit.ly/2n3ekZe、英語) を参照してください。InSpec を拡張して独自のリソースを簡単に用意でき、既定ではサポートされない構成項目や、特定のアプリケーション固有の構成項目をチェックすることもできます。

メタデータを含める

InSpec では、準拠の規則についてのメタデータを含めることができます。メタデータを使って、具体的な規制やセキュリティ要件にテストを結び付けることができます。これまでの準拠要件は、ドキュメント、スプレッドシートなどの実用的ではない形式で発行されていました。このような準拠の公式ドキュメントに記載された情報は、準拠のポリシーが重要な理由の背景を管理者に伝える大切なものです。ただし、多くの場合あまり実用的とは言えません。

このような情報をメタデータとして含む InSpec 規則の例を図 2 に示します。

図 2 準拠の規則についてのメタデータを含む InSpec の例

control 'sshd-8' do
  impact 0.6
  title 'Server: Configure the service port'
  desc '
    Always specify which port the SSH server should listen to.
    Prevent unexpected settings.
  '
  tag 'ssh','sshd','openssh-server'
  tag cce: 'CCE-27072-8'
  ref 'NSA-RH6-STIG - Section 3.5.2.1',
    url: 'https://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf'
  describe sshd_config do
    its('Port') { should eq('22') }
  end
end

これは、ssh-8 という規則 (統制) の例です。impact、title、および desc の各フィールドは、それぞれ規則の重要性、目的、説明を定義します。tag フィールドは省略可能な情報を含みます。ref フィールドは、外部ドキュメントを参照します。

describe フィールドは、規則を含むブロックの開始点を示します。テスト対象のリソースは sshd_config です。これは、Linux や Unix プラットフォームの OpenSSH デーモンです。この規則は、SSH サーバーがポート 22 をリッスンするかどうかを確認するテストを行います。

注意すべき重要な点は 3 つです。第 1 に、このメタデータがなければ、この規則が分離され、文脈が不足することになります。第 2 に、すべての関連情報がこの規則に含まれています。他のドキュメントに照らしてチェックする必要はありません。第 3 に、この InSpec 言語は非常に簡単に読み取れます。コンプライアンス担当者は、プログラマではない場合があります。こうした関係者は、規則のテスト項目やメタデータによって、規則の存在意義や監査する要件を理解することができます。関係者が、独自の規則を指定することも考えられます。

オープンソースプロファイルの使用

利用を容易にするために、InSpec にはすべての関連規則やメタデータを事前に含む多くのオープンソースプロファイルが用意されています。たとえば、DevSec Linux Baseline プロファイルと DevSec Apache Baseline プロファイルがあります。これらのプロファイルは、こちら (bit.ly/2mBVXNr) からダウンロードできます。

InSpec が提供する多くのオープンソースプロファイルは、システムセキュリティの業界標準であるインターネットセキュリティセンター (CIS) のベンチマークに基づいています。CIS のベースラインは開始点として適切ですが、特定の準拠ニーズを満たすように変更が必要になることもあります。InSpec では、独自のプロファイルの作成や、他のプロファイルからの規則の継承を許可しています。また、プロファイルの規則を無視することもできるようにしています。無視することが可能であれば、InSpec が提供するオープンソースプロファイルを直接変更する必要がなくなります。必要なオープンソースプロファイルを継承する独自のプロファイルを作成し、該当しない規則を無視することができます。新しいオープンソースプロファイルをリリースするときに、カスタムルールを変更する必要なく、オープンソース規則のバージョンを簡単に更新できます。

ホストのスキャン

InSpec では、クライアントサーバーモデルを使用します。つまり、集中管理ワークステーションからリモートシステムを監査できます。また、Chef Automate (chef.io/automate) など、連続自動システムの一部として InSpec スキャンを実行するオプションもあります。このオプションの簡単な例は、後ほど紹介します。

準拠のスキャンを実行するには、ターゲットシステムが必要です。ターゲットシステムとは、テスト対象のサーバーと準拠プロファイルです。準拠プロファイルとは、ターゲットシステムのテストに使用する一連の規則です。今回の例のターゲットシステムは Windows Server です。さらに、CIS の定義に従った Dev-Sec Windows ベースラインを使用します。このベースラインは GitHub のリポジトリに格納されています。図 3 に InSpec の実行例を示します。

図 3 InSpec の実行例

結果を調べると、この実行では準拠の CIS ベースラインを満たしていない構成設定が数多くあることが示されています。テスト対象のサーバーは、大手クラウドプロバイダーが提供する既定の Windows Server 2016 イメージであることがわかります。そのため、ネットワークが自社のセキュリティポリシーにどの程度適切に準拠するかを、InSpec が可視化するようすを即座に確認できます。

最初に失敗したテスト cis-enforce-password-history-1.1.1 の実際の InSpec 規則を見ると、規則を対応可能な作業に変換する方法がわかります。

control 'cis-enforce-password-history-1.1.1' do
  impact 0.7
  title '1.1.1 Set Enforce password history to 24 or more passwords'
  desc 'Set Enforce password history to 24 or more passwords'
  describe security_policy do
    its('PasswordHistorySize') { should be >= 24 }
  end
end

ポリシーではパスワード履歴のエントリを 24 件以上保持することを求めていますが、実際には履歴がまったく保持されていないため、テストに失敗しています。規則に準拠するように、現在の構成設定を変更する必要があることは明らかです。

自動リリースパイプラインでの InSpec の使用

InSpec はそれ自体でもシステムの準拠の管理に役立ちますが、標準リリースパイプラインの一部として InSpec を実行する一連の自動テストとしても実行できます。InSpec テストは、準拠の品質ゲートとして機能するように簡単に追加できます。ここでは、InSpec を Chef Automate と併用します。

Chef Automate は、インフラストラクチャとアプリケーションの管理と配置向けの統合ソリューションです。InSpec や Chef などのオープンソース製品を基盤とし、インフラストラクチャの自動化を目的にしています。Chef Automate は、変更管理用の自動パイプラインを提供し、これらの変更の可視性を確保する機能を含んでいます。

Chef Automate を使うと、InSpec の準拠テストをオンデマンドで実行し、ダッシュボードで結果を確認して、問題を修正できます。また、必要に応じていつでも監査レポートを生成できます。

たとえば、パッチ管理は IT セキュリティで最も重要な部分の 1 つです。重要なのは、最新ではないシステムを特定してアップグレードできることです。PCI データセキュリティスタンダード (PCI DS) など、ほとんどの規制フレームワークでは、これが必須になります。システムが最新になるよう、初期の特定から修正までのプロセス全体の管理に Chef Automate を使用できます。

まず、システムをスキャンして、ポリシーに準拠するかどうかと、ソフトウェアが最新かどうかを確認します。その結果、インフラストラクチャの状態を示すレポートを受け取ります。図 4 にそのレポートの例を示します。レポートでは、準拠要件をどの程度満たしているかという観点で、ネットワーク内のサーバーの状態が示されます。

図 4 準拠レポートの例

レポートを受け取ったら、Chef DK を使用して修正方法を組み立て、その後運用環境に配置する前にローカルにテストします。Chef DK には、コードの作成とテストに必要なツールがすべて含まれています。

変更に問題がなければ、修正内容を配置するために、Chef Automate パイプラインを通じて修正内容を送信します。このパイプラインには、変更のテスト段階と、変更の効果の確認段階が含まれています。パイプラインの中、2 つの手動ゲートがあります。1 つはコードレビューのゲートで、もう 1 つはコードをリリース環境にコードを送信するゲートです。2 つのゲートのいずれかまたは両方でコンプライアンスとセキュリティの担当者に関与して、リリースプロセスに積極的に取り組んでいることを確認します。

最後に、変更がパイプラインのすべての段階を通過したら、Chef サーバーにその変更を送信します。その後、Chef サーバーはノードを最新状態にする作業を開始します。変更を配置すると、Chef Automate では、インフラストラクチャで行われたすべてのことを確認できるようになります。

InSpec による準拠の自動化

インドの銀行最大手の 1 行が、銀行取引の大部分を担う銀行業務サービス部門で InSpec の使用に乗り出しました。銀行では、規制への準拠が特に重要です。この部門では、開発環境、テスト環境、運用環境を構成する約 500 台の HP-UX サーバーがあります。

当然、同行には従わなくてはならない規制とセキュリティのガイドラインがあり、チームはサーバーがそれらに準拠するように毎月チェックしています。約 100 項目のチェック項目があり、InSpec を使うまではこれを手作業でチェックしていました。このプロセスは非常に困難になっていました。チームは各コンピューターにログインし、構成設定をチェックして、結果を書面にし、記録していたのです。1 項目のチェックに約 5 分かかるため、1 台のサーバーを検証するだけでも約 8 時間かかります。

チームが InSpec による自動準拠を使い始めると、その効果は明らかでした。全体のスキャン結果は数分で確認できます。チームは準拠しているサーバーと準拠していないサーバーの台数を確認し、それを基に迅速に判断できます。1 台のサーバーに 500 分かかっていたチェックが、2 分で終わるようになります。

また、InSpec によって同行の監査担当者を簡単に満足させられるようにもなります。IT 監査担当者は時折特定のコンピューターの状態確認を求めることがあり、このような情報の取得に時間がかかっていました。チームのメンバーは手作業でスクリプトを実行し、出力を入手後、報告書を適切に仕上げる必要がありました。それがクリック 1 回で、チームは監査担当者にすぐにチェック結果を示せるようになります。

また、InSpec は人間にも理解できるため、学習も簡単です。セキュリティや監査のベンダーの大半がバイナリ形式を使用し、使い方が難しいツールを使用しています。銀行業務サービス部門のメンバーが InSpec を見たとき、学習曲線が非常に小さいため、数日で簡単に覚えられると感じました (これについては、Learn Chef Web サイト bit.ly/2mGthmE (英語) をご覧ください)。

まとめ

InSpec はオープンソースのテスト言語で、準拠をコードとして扱えるようにします。準拠をコードにすると、規則があいまいではなくなり、チーム全員が理解できるようになります。開発者は求められている標準がわかり、監査担当者はテスト対象の項目が正確にわかります。InSpec により、ドキュメントや手動のチェックリストを、目的が明確なプログラムテストに置き換えることができます。

また、準拠テストを配置パイプラインに統合し、セキュリティポリシーへの準拠テストを自動化できます。必要に応じて何度でもテストを実行し、すべての変更について準拠テストを始めて、開発プロセスの早い段階で問題を見つけることによって、適切な状態にしてから運用環境にリリースできます。

Michael Ducy は Chef Software のオープンソース製品マーケティング部門のディレクターです。彼は、20 年近く、オープンソースソフトウェアの使用、管理、推奨に携わってきました。Ducy は Linux のシステムエンジニア、IT インストラクター、プリセールスエンジニアなど、テクノロジに関する多くの役割を担当してきました。彼は常に地域社会に広く貢献することに関心を持っており、Twitter には @mfdii (英語) からアクセスできます。

この記事のレビューに協力してくれた技術スタッフの Bakh Inamov、Adam Leff、および Roberta Leibovitz に心より感謝いたします。

次の方法で共有