2016年10月13日

セキュリティの世界からちょっと距離が離れてしまったseiriosです。最近では、NGINXとかRTMPとかOBSとかと戦っています。

前回の記事Vulsを試してみようから時間が経ってしまい、Vulsも随分良くなってきていますので、またどこかで更新記事を書こうとは思いますが、今日は少し観点を変えて、PCI/DSS対応のシステムにVulsを導入する場合に考えておいた方が良いことを書いてみることにします。

よろしくお付き合いのほどお願いいたします。

PCI/DSSってなに?

当ブログを見られるような方々にPCI/DSSを今更説明するのもどうかとは思いますが、とても簡単に説明してみます。

PCI/DSSは、Payment Card Industry / Data Security Standards の略号です。詳しいことはWikipedia などを参照していただければいいですが、要約すると、

JCB, American Express, Discover, Master Card, VISA の5社で設立した PCI SSC(PCI Security Standards Council) によって策定されたセキュリティ規格

のことです。従って、PCI/DSSの目的は、当然に

クレジットカード会員データを安全に取り扱う

ということになります。明確ですね。

この規格、細かく見て行くと様々に大変なのですが、今回はVulsと関係ある部分だけ見て行くことにします。

なお、本記事は、PCI/DSS ver 3.2 を元に記載しています。2016/9/16 現在日本語訳が読めるのは ver 3.0 ですが、細かい修正はあるものの、大枠では問題になるほどの差はないので、興味があればPCI/DSS 3.0の翻訳を取り寄せて見てはいかがでしょうか?

なお、PCI/SSCのサイトに行っても日本語ではver 3.0しか入手できません。ver 3.2を必要とする方は、PCI/SSCのサイトの右上、「言語の選択」から英語を選ぶと英語のページに遷移するので、そこから探してください。

なぜPCI/DSS?

クレジットカードは、規格が古くに策定されました。大雑把な規格としては

  • カードの形状は ISO/IEC7810 及び ISO/IEC7812 で規定
  • カードの磁気ストライプに記載される情報はISO/IEC 7811 で規定
  • ICカードは EMV (ユーロペイ、Master Card、VISA) が策定した規格を事実上の標準として採用

があります。ICカードの規格は比較的新しいと言えますが、例えばISO/IEC 7811は初版の公開が 1989 年です。従って、インターネット経由での決済に利用するなどという事態は「想像の外」だったわけです。

クレジットカードの不正利用は、昔からそれなりにはありました。ただ、物理的に不正カードを作成し、何らかの方法でそれを利用することができなければならないわけで、それなりのハードルはありました。

しかし、インターネットの普及と利用者の増大に伴い、インターネット経由でのカード決済が行えるようになると、決済処理が爆発的に増え、しかも物理的な偽造カードを利用するわけではないことから、不正利用の敷居が下がります。その結果、当然不正利用が爆発的に増えました。このような事情で、カード情報の保護を含めた対策をすることが急務になりました。

これが、PCI/DSS 策定の背景です。

PCI/DSSとVuls

やっと本題に入りました。

まずVulsについてです。

Vulsは、ものすごく大雑把にいうと、

ある情報システムに対して、導入されている様々なアプリケーションに存在する既知の脆弱性を、公開されているCVE/NVDなどのデータベースに登録されている情報と付き合わせて、検出するためのツール

ということになります。

従って、PCI/DSSによって規定されている

  • 6. 安全性の高いシステムとアプリケーションを開発し、保守する

という条項に対する解決策の一つとなりえます。特に6.1項にある「セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を特定し、新たに発見されたセキュ リティの脆弱性にリスクのランクを割り当てるプロセスを確立する」という要件に対して、十分に役に立つものとなりえます。

では、実際にVulsを用いて PCI/DSS 対応するには Vuls を導入すれば良いか?となると、当然考えるべき点が出てきます。何を考えなければならないのでしょうか?

PCI/DSSでは、システムを保護するために、アクセス権管理を非常にしつこく要件に記載しています。大雑把にまとめると

  • システムコンポーネントとカード会員データへのアクセスを、業務上必要な人に限定する
  • システムコンポーネントで、ユーザの必要性に基づいてアクセスが制限され、特に許可のない場合は「すべてを拒否」に設定された、アクセス制御システムを確立する
  • 一意のIDを割り当てることに加え 、すべてのユーザを認証するため、 次の方法の少なくとも1つを使用することで、すべてのシステムコンポーネント上での顧客以外のユーザと管理者の適切なユーザ認証管理を確認する。
  • グループ、共有、または汎用のIDやパスワード、または他の認証方法が使用されていない状態にする

これをさらにまとめると

  • 第6条:脆弱性を素早く発見し、対処しなさい
  • 第7条、第8条:ちゃんと権限を分離して、「やっていいことしかできない」ようにしなさい

となります。

このPCI/DSS規格は「人」がシステム保守をすることを前提として考慮されたのではないかと考えられます。従って、Vulsのような「システムが作業する」ということに関して、様々な部分で判断に迷う部分が多くあるのです。

 

Vulsを「できる限り」PCI/DSSに従った形で使う

Vuls を利用する場合、「Vulsを動作させる機器」と「Vulsによって検査される対象機器」が登場します。このそれぞれに関して、以下のような対応を取れば、PCI/DSSの審査機関でも、あまり問題視しないのではないかと考えています。

  1. 検査対象機器側
    • 対象機器には、Vulsが命令をするためのアカウントを作成する
      • このアカウントはRoot/Administrator特権(以下管理特権)を付与してはならない
      • このアカウントは、パスワード認証でログインできてはならない。代わりに、sshによるRSA認証を利用することでパスワードを利用しないようにする。
      • 対象機器には、このアカウント用のsshの公開鍵のみを配置し、秘密鍵は配置しない
    • システムによってはVulsが管理特権を必要とする。その場合、このアカウントはsudoを用いることによって管理特権を取得することができるようにする
      • 現時点(2016/9/16)では、Amazon Linux及びFreeBSDのみ管理特権を必要としない。RedHat Enterprise Linux、CentOS、Ubuntu、Debianなど多くのLinux系ディストリビューションは管理特権を必要とするので注意が必要
    • sudoによる管理特権を付与する場合、sudoへの設定(sudoersファイルに記載する)によって、Vulsが必要とする最小限のコマンドのみを実行できるようにする
  2. Vulsを動作させる機器
    • Vulsを動作させる機器には、対象ノードの様々な脆弱性情報が集中的に記録される。従って、厳しい制限を課す必要がある
      • 可能であれば、Vuls関連の処理のみを実行させるようにし、他のサービスを実施させない
      • ログインできるユーザーを十分に検討し、必要最小限のユーザーしか登録しない
      • Vulsが出力したデータは正しく保護し、書き換えなどが発生しないようにする
      • VulsRepoなどで作成した情報を公開する場合、情報にアクセスできる人を限定し、かつ、アクセス記録を取得する
  3. Vuls自身の運用について
    • Vulsの参照する情報を常に最新のものに更新すること
      • Vulsは、NVDやJVN等の外部DBと、パッケージシステムが提供している情報を利用して検査対象の脆弱性を判断している
      • このうち、外部DBから取得した情報は一度Vulsが参照できる内部DB(Sqliteを利用しています)に蓄積する
      • この内部DBの更新を定期的に行うこと
    • Vuls自身の更新も常に視野に入れる
      • Vulsは外部からの接続を受け入れることはなく、比較的安全
      • しかし、Vuls自体は現在も開発が続いているので、できるだけ安定稼働する最新版に更新することが望ましい

最後に

以上、非常に簡単にVulsとPCI/DSSに関して記載しました。

Vulsは非常に導入が簡単な割にうまく利用すると現状の把握にとても役に立つツールです。特にサービスシステムの状況を把握するためにはとても有用なツールと言えます。

PCI/DSSの要件は、色々言いたいことはあるにしても、この程度はやっておくべきと言える部分がたくさんあり、システムの安全性を確保する際の指針としても利用できます。

この記事が何らかの参考になれば幸いです。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。