ISMS更新審査をエンジニアとして通した話

ISMSのサーベイランス審査（更新審査）とは、初回の認証取得後に定期的に行われる維持審査のことです。初回取得では制度や文書体系の整備そのものが問われるのに対し、更新審査では「その運用が実際に回っているか」が主眼になります。つまり、紙の上の規程よりも、日々の実態と証跡が問われる場です。

「審査が近づくと急ピッチで準備に追われる」という話は珍しくありません。しかしそのプレッシャーの多くは、「全項目を完全に満たさなければ不合格になる」という誤解から来ています。実際に審査を経験してみると、そのイメージは相当ズレていました。以下では、実際に審査官とやり取りした場面と、エンジニアとして取り組んだ自動化の話を交えながら、そのギャップを整理します。

Linuxユーザー管理に関するプッシュバック

今回の審査で最も印象に残ったのが、EC2上のLinuxインスタンスのユーザー管理に関するリクエストでした。審査官から「全ユーザーにパスワードを設定するか、使用されていないユーザーおよびグループを削除してください」という指摘が入りました。

一見もっともな要求ですが、Linuxに詳しいエンジニアであればすぐに気づく問題があります。Linuxには daemon、bin、sys といったシステムユーザーが存在しており、これらはOSのプロセスを動かすために必要なアカウントです。パスワードは設定されていないのが正常な状態で、ログインシェルも /sbin/nologin に設定されており、そもそも対話的なログインは不可能な設計になっています。

これらのユーザーを削除したり、無理やりパスワードを設定したりすることは、システムの安定性を損なうリスクがあります。

審査官への回答と結果

審査官に対して、以下の点を説明しました。

daemon、bin、sys 等はOSの動作に必要なシステムアカウントであること
ログインシェルが /sbin/nologin に設定されており、対話的ログインが不可能であること
パスワードが設定されていないこと自体がセキュリティ上問題ではなく、むしろ意図的な設計であること
削除した場合、システムの動作に影響が出る可能性があること

この説明を受けた審査官は、リクエストを取り下げました。重要なのは「できない」ではなく「なぜそうなっているか」を説明できることです。セキュリティの文脈では、根拠のない変更よりも、意図を持った設計の方が評価されます。

Ansibleによる監査作業の自動化

更新審査では、証跡の提出が求められる場面が多くあります。「このサーバーの設定を確認してください」「ユーザー一覧を出してください」といったリクエストに対して、手作業でSSHしてコマンドを叩き、スクリーンショットを撮る——という対応は非効率です。

そこで、Ansibleを使って証跡収集を自動化しました。

実装のポイント

証跡収集Playbookでは、対象サーバーに対して以下を自動実行します。

- name: ユーザー一覧を収集
  command: cat /etc/passwd
  register: passwd_output

- name: ログインシェルの確認
  command: grep -v nologin /etc/passwd
  register: login_users

- name: 結果をファイルに保存
  copy:
    content: "{{ passwd_output.stdout }}\n\n{{ login_users.stdout }}"
    dest: "/tmp/audit-{{ inventory_hostname }}-{{ ansible_date_time.date }}.txt"

これにより、複数台のサーバーに対する証跡収集が数分で完了します。また、Playbookとして管理することで、「どのコマンドで何を確認したか」自体がドキュメントになります。

自動化のメリット

再現性: 次の審査でも同じ手順で証跡を取れる
網羅性: 手作業では漏れがちなサーバーも確実に対象に含められる
監査証跡の標準化: 出力フォーマットが統一されるため、審査官への提出資料がきれいにまとまる

「完璧に対応できなくても通る」という実態

更新審査を通じて学んだ最大の教訓は、「完璧に対応できなくても、理由とワークアラウンドが説明できれば通る」ということです。

審査官は意地悪をしに来ているわけではありません。ISMSの目的はリスクの管理であり、「すべてを完璧に実装する」ことよりも「リスクを認識し、合理的な対策を取っているか」が問われます。

実際にプッシュバックが受け入れられた経験からも分かるように、技術的な根拠をもって「この設計は意図的なものであり、セキュリティ上問題ない」と説明できれば、審査官はそれを尊重します。

大切なのは以下の3点です。

理由を説明できる: なぜその設定・構成になっているのかを答えられること
リスクを認識している: 問題があるとすれば何かを把握していること
代替策がある: 完全対応できない場合でも、同等のセキュリティを担保する手段があること

まとめ

ISMSの更新審査は、「監査に向けた特別な対応」ではなく、「日常の運用がISMSの精神に沿っているかの確認」です。普段からリスクを意識し、設計の意図を記録し、変更を追跡できる状態を維持していれば、審査は怖くありません。

そして、Ansibleのような自動化ツールを使って証跡収集を仕組み化しておくことで、審査のたびに発生する準備コストを大幅に削減できます。運用の自動化は、セキュリティと効率性の両立に直結します。