認証スキャン開始時期、迫る

はじめに
一番やっかいなのは特権IDの授受
実施事例：システム開発A社
実施事例：決済B社
最後に
お問い合わせ

はじめに

本コラムでは、いよいよ実施期日まで一年を切った認証スキャンのポイントと、現在までに対応した所感を述べたいと思います。

2025年4月には完全にPCI DSS4.0に移行が済んでいる必要があります。
最低一回は認証スキャンを事前に実施しておく必要がありますので、早いところでは2025年１月頃には認証スキャンを実施する必要があります。
特権IDをスキャン事業者に提供しなければならないため、強い権限を持つIDの発行から削除までのライフサイクルなど、運用ルールを決める必要があります。

また、スキャン事業者が対象 OS に管理アクセスできるようにネットワーク構成も設定変更を伴う場合があります。
内部で動作しているソフトウェアすべての脆弱性が検出されてきますので、それをどのように整理していくか、また、認証スキャンができないOSもありますのでその整理も考える必要があります。

いよいよ待ったなし！！

一番やっかいなのは特権IDの授受

認証スキャン用に診断ベンダや診断実施者に対し、サーバにフルアクセスできる特権IDとパスワードを渡す必要があります。

OSによって、ID/PW以外の情報も必要
Linux:権限昇格が必要なアカウントの場合は、sudo情報が必要
Windows:ドメイン所属アカウントの場合は、ドメイン情報が必要
→場合によってはユーザーアカウント制御（UAC）設定やレジストリ設定の変更が必要

実施事例：システム開発A社

認証スキャンを導入する事例も増えてきましたので、あるシステム会社を事例として、認証スキャンで変更のあったところについて触れていきたいと思います。

特権IDの受け渡し

システム会社A社様では、脆弱検査用に新たな特権IDを作成し、検査の時に限りIDとパスワードの貸し出しをおこない、検査完了時にそのパスワードを無効とするという運用を採用されました。
Windows環境はADで一元管理されているのでまだいいのですが、Linux環境は１台ずつの対応が必要なため、これが大変です。
このIDもPCI DSSのアカウント管理の対象になりますので、我々も使用者を限定し、お客様の目の前でID設定と削除を実施しています。

意外と早いスキャン速度

これは想定外でした。
これまでのノンクレデンシャルスキャンとは違い、多数のファイルやレジストリにアクセスするので時間が掛かるものと考えていました。
しかし、実際に認証スキャンを実施すると非認証スキャンよりも早く終わる傾向にあります。
これはネットワークの通信を通して脆弱性を見つけていくやり方よりも、ファイルに直接アクセスして検査しているためと考えられます。

認証スキャンという検査全体では、IDの受け渡しで合ったり、IDの埋め込み、大量の脆弱性のとりまとめなどがあって、時間が増えるところはありますが、スキャン時間が短くなる傾向にあるというのは唯一ありがたいと思ったところです。

管理アクセスできるようにする必要がある

スキャナから対象OSに管理アクセスできないとそもそも認証スキャンができません。

本お客様は、サーバが設置されているサーバセグメントから検査用PCを利用して検査していましたので、こちらはネットワークの構成変更等は発生せずにスムーズに移行ができました。
サーバセグメントからのアクセスが禁止されて、定まった所からしか通信が許されていないような環境の場合には検討事項が増えると思いますので、やはりどのように検査をしていくのか早めの検討が必要だと思います。

認証スキャンができない対象

SSHの管理アクセスはできても、ツールによる認証スキャンができないケースがあります。

SSHで通信ができさえすれば認証スキャンが可能というわけではなく、ツール側が対象OSのサポートをしているかが重要になってきます。
サポート外のOSであれば、ディレクトリ情報や設定情報が違いますので当然認証スキャンはできません。
いざSSHで接続ができても認証スキャンはできなかったりするので、やってみるまでわからないというところはあります。
PCI DSSv4.0では認証スキャンができない場合は管理台帳で管理しなさいとありますので、どのように検証してできなかったかと、代替としてどのように考えていくかをまとめていく必要があります。

また、そのような進め方でいいか早めにQSAに確認しておくことで実審査の時にスムーズに進められると思います。
こちらはお客様と情報連携して進めていく必要があると考えます。

実施事例：決済B社

認証スキャン導入前の課題

このお客様は、他社には特権IDとパスワードは渡さないというルールがありました。
検証PCの認証情報をお客様に入れていただき、終了後はお客様に消していただくという運用を提案させていただきましたが、万が一でも検査用PCにログイン情報が残ると困るということでした。

ログインID受け渡し不可のお客様への対応

IDとパスワードの開示がNGですので、お客様環境にご用意いただいた端末へ脆弱性スキャンをセットアップ、認証情報のセットはお客様に登録いただき、その他の作業は当社にて対応をさせていただきました。
イレギュラーなケースではありますがこのような対応をとることで認証スキャンの実施を実現しました。

最後に

認証スキャンは、これまでの内部スキャンと比べて検討するべきことがあります。
実施後は、これまで脆弱性が検出されなかったシステムでも大量に検出されたりします。こちらの対応の検討も必要ですので、早めに対応することが必要だと考えます。

また、上記で紹介したB社のようなケースでは、「内製化」を検討してみるのもありだと思います。
ご自身でスキャンをしてみることでセキュリティのノウハウが蓄積されます。
TISが採用している診断ツールや運用方法の導入により、時間や外部委託先の都合に縛られずに自社で脆弱性診断を実行することが可能になります。
これにより、システムのセキュリティ状況の把握と、最優先で対処すべき脆弱性の対応が可能になります。

TISはお客様との伴走を第一に考えております。本コラムがお客様のセキュリティ維持、さらには強化に一役買えれば幸いです。