「オンプレミスに比較して、クラウドはセキュリティが心配・・・」と言うユーザーに対して「クラウドベンダーと御社とどっちのセキュリティが上だと思ってるの？」というのは昔から良く話しとして見かける。実はクラウドサービスのセキュリティで気をつけるべき視点がひとつある。インシデント発生時に速やかな対応が可能か否かだ。
一流のクラウドベンダーならユーザー側に起因するインシデント発生時の対応も考慮されている。だが、二流三流のクラウドベンダーとなるとかなり怪しい。ユーザー側の原因でインシデントが発生した時に、影響範囲特定に必要なログ等の提供を受けられない可能性がかなり高い。例えば以下のシナリオのような状況が考えられる。
インシデントシナリオ＃1
自社のWEBサービスがSQLインジェクション攻撃を受けた。この場合は影響範囲の調査にデータベースサーバの監査ログが重要な役割を果たす。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、監査ログには他のユーザー企業の発行するSQL文まで含まれてしまう。ベンダー企業が監査ログをユーザー企業ごとに分割するような対策を事前に取ってない限り、迅速な対応は期待できない。
インシデントシナリオ＃2
メールアカウントのユーザーIDとパスワードが漏洩して第三者が閲覧した可能性がある。この場合にはメールサーバーの認証ログを閲覧して、不自然なな時間帯や接続元からの認証、認証エラーの有無を確認したい。もしこの時、ベンダーの提供するデータベースが他のユーザー企業とインスタンスを共有している場合、そこには他のユーザー企業のログも含まれている。さらには通信事業者には通信の秘密を守る義務が課せられている。通信時間帯や接続元IPアドレスは通信の秘密に含まれるため、頑なに開示してもらえない可能性がある。こうなると被害届をだして事件化しないと、影響範囲の特定も出来なくなってしまう。
無論、きちんとしたベンダーは回答を用意している。AWS AuroraDBやSQL Azureには監査ログの機能がある。オブジェクトストレージのS3はアクセスログを提供している。GSuiteやOffice365も認証ログを提供している。
対して国内ベンダーに目を向けると、大手ベンダーでもその辺りがかなり弱い。
例えばさくらインターネットがS3互換としているオブジェクトストレージにはアクセスログの機能が無い。
あるいはNTT Communicationのメールホスティングサービスにはメールの送信ログに対する検索機能はあるが、認証ログの提供はない。法的な問題もあるので提供が難しいのは分かるが、せめて認証成功のログ程度はないとインシデント発生時に対応出来ない。
ベンダーの多くは電気通信事業者として「通信の秘密」に関する義務をおっている。何時何処と通信をおこなったかは「通信の秘密」に含まれるため、電気通信事業者としては安易にログを開示する事は出来ない。ユーザー企業に公開できるのは、ユーザー企業の管理下にあるシステムのログだけになるが、事前に準備を整えていない限り共有部分のログ提供には時間がかかる。
クラウドサービスを採用するにあたっては、セキュリティ監査に耐えるだけのログ出力機能があるか否かは確認した方が良い。もしそれらのログ出力機能が無く、インシデント発生時に相応の対応が必要なら、契約に調査対応への協力義務を盛り込む程度のことは検討しなてくはならない。
※クラウドベンダーの対応状況は2019年9月時点のもの