あらゆるセキュリティチェックシートで80点以上を出すための対策集

企業向けのWebサービスを提供していると、顧客からセキュリティチェックシートへの記入を求められることがあります。これが企業によって内容がまちまちだったりするので、作業の負担もばかになりません。最近は自治体や大企業など、各々のセキュリティ要件を満たせないサービスは導入してもらえないケースが増えてきました。ある日、営業から開発にこれ全部満たしてるよねと投げられて、そんなの聞いてないからやってませんよとならないためには、開発前からセキュリティ対策には気を配っておく必要があります。この記事ではあらゆるセキュリティチェックシートで80点以上を出すことを目指して、抑えておくべきポイントをまとめました。インフラはAWSを想定していますが、それ以外でも使えるようにしています。

セキュリティチェックシートの雛形はあるか

「セキュリティチェックシート」で検索してみると、いろんなベンダーからセキュリティチェックシートが公開されています。それらの多くは、「経済産業省：クラウドサービス利用のための情報セキュリティマネジメントガイドライン」なるものに準拠してますよと書かれているのですが、そのガイドラインが2013年の策定と古いものであり、現在経済産業省のサイトからリンクされているページを見つけることはできませんでした（ファイルはこちらからダウンロードできます）。代わりに総務省から、2021年版「クラウドサービス提供における情報セキュリティ対策ガイドライン」が公開されているので、そちらをベースとし、各社が公開しているセキュリティチェックシートから項目を加えました。またセキュリティチェックシートには運用体制や運用ルール、インフラに関する項目も多いのですが、そういったものは除外しています。「クラウドサービス提供における情報セキュリティ対策ガイドライン」にはセキュリティチェックシートのテンプレートもあるので、合わせてそちらも参考にしてみてください。

対応表

重要度は対応が必須のものをMUST、チェックシートのスコア向上のために対応すべきものをSHOULDとしました。

具体的な対策

それでは具体的な対策について見てきましょう。

通信の暗号化(MUST)

利用者とサービスとの通信経路はすべて暗号化します。またSSL3.0、TLS1.0、TLS1.1 といった、安全性の低い暗号化方式の使用を禁止します。これらの暗号化方式は今はほぼ使われていないので、ALBやCloudFrontの設定でTLS 1.2以上（可能であれば1.3以上）を有効にします。

ストレージの暗号化(SHOULD)

データベースについては標準の暗号化機能を利用します。MySQLは5.7から透過的データ暗号化（TDE）がサポートされています。有効化すると性能が10%程度悪くなるようなので、事前に検証するのが望ましいです。OracleやPostgreSQLなどのRDBMSでもデータ暗号化の機能があります。DynamoDBやRedisなどを使っている場合も、暗号化されているかどうか忘れず確認するようにしましょう。アップロードファイルについては、クラウドストレージを使うのがほとんどだと思います。S3だと標準で暗号化が有効になっています。自前で共有ストレージを作る場合はOSレベルでパーティションの暗号化などを行ってください。

時刻の同期(MUST)

時刻がずれていると脆弱性を生む原因となるため、全OSで時刻の同期は必ずやりましょう。

バックアップ(MUST)

ファイルストレージやデータベースのデータは必ずバックアップを取得し、バックアップから復旧できることを確認します。S3などのクラウドストレージについては、バージョン管理を有効にして誤ってファイルが変更されてしまうことを防ぎます。データベースについては必ず毎日バックアップを取りましょう。

冗長化(SHOULD)

ある機器やサービスに障害が起こると、システム全体が機能しなくなることを単一障害点（SPOF）といいます。サービスを安全に運用するには、冗長化によって単一障害点をなくす必要があります。AWSのマネージドサービス（S3やDynamoDBなど）については何もしなくてもデータが複数のアベイラビリティゾーンに分散されており、ひとつのデータセンターで障害が起こっても問題なく動作するようになっています。

管理サーバーのセキュリティ対策(MUST)

セキュリティパッチの適用

ベンダーが提供しているセキュリティパッチを適用して、OSやアプリケーションを常に最新の状態に保ちます。

管理者権限や特権ユーティリティの制限

Webアプリケーションやワーカーのプロセスを管理者権限で実行しないようにします。また不要なサービスやデーモンを起動しないようにします。コンテナではUSERを指定してサービスを起動するようにしましょう。

マネージドサービスも選択肢に

Lambdaなどのサーバーレス構成を採用することで、管理が必要なサーバーを減らし、セキュリティを高めることができます。

インフラの構成管理(SHOULD)

インフラのリソース構成を管理します。誰がいつ、どのように変更したかを記録しておくことで、セキュリティリスクのある操作や問題のある構成を検出することができます。

AWSの場合はCloudTrailやAWS Configを使えば簡単に実現できます。

WAF・不正アクセス防止対策(SHOULD)

脆弱性を悪用した攻撃を防止する

WAFの導入により、ルールベースで脆弱性を悪用したアクセスをブロックすることができます。自前でIPSやIDSを導入する方法もあります。

DoS攻撃の対策を行う

WAFでレートベースのルールを導入する方法や、ボットからのアクセスを無効化する方法など、対策レベルによっていくつか方法があります。

モニタリング・障害検知(MUST)

セキュリティインシデントや、障害をモニタリングして検知できるようにします。

• クラウドサービス及び、ネットワークに対するパフォーマンス監視
• 構成要素の死活監視・障害監視
• エラーの監視
• 不正アクセス・不正利用の監視

AWSの場合はCloudWatchでアラームを設定して監視します。問題を検知した場合は、メールやSlackに通知して、速やかに対応ができるようにします。サービス停止など重要な障害が発生した場合は、速やかにホームページやSNS、メールなどを使ってユーザーに連絡するようにしましょう。

パスワード管理(MUST)

パスワードの管理機能について。管理者がユーザーのパスワードを設定する場合は、あとでユーザーが自分で変更できるようにしないといけません。あとはおなじみのやつですね。

• パスワードは利用者自身が設定する。(MUST)
• パスワードはハッシュ化して保存する。いかなるパスワードであっても平文で保存しない。(MUST)
• 脆弱なパスワードの使用を禁止する（最小文字数を設定し、記号も使用可能とするなど）。(MUST)
• 変更時は以前登録したパスワードを利用できないようにする。(MUST)

認証・アクセス制限(MUST)

企業向けのシステムを作られている方ならおなじみの内容と思いますが、最近はパスキーのような二要素認証の採用が必須となることが増えています。強制ログアウトは24時間くらいが一般的みたいです。

• 指定回数以上認証に失敗したユーザーはロックまたは一定時間認証できないようにする。(MUST)
• 接続元IPアドレスによりアクセスを制限できる。(SHOULD)
• クライアント証明書によりアクセスを制限できる。(MAY)
• 多要素認証やシングルサインオンを利用することができる。(MUST)
• ログイン後一定時間以上の操作がない場合にログアウトさせる。(MUST)
• 同じアカウントに同時にログインできるセッション数を制限する。(MAY)

ロギング(MUST)

一般的に、以下のような種類のログを記録します。どのログも不正アクセスや改ざんがなされないように、アクセス制御や暗号化などによる保護を行います。AWSの場合はアクセスログとシステムログは普通にCloudWatch Logsを使うことになると思います。監査ログは必要に応じてデータベースに持つなど検討してみてください。

監査（操作）ログは1年、それ以外は90日保存しておけばよいようです。

監査（操作）ログ

ログイン履歴や、ユーザーの操作を記録するログを取得します。監査ログは管理画面などから、ユーザーに提供できるのが望ましいです。

アクセスログ

操作ログと似ていますがこちらはユーザーに提供せず、サービス提供者が運用上の目的で使用します。

システムログ

システムの例外処理やエラー、システム障害を記録します。

顧客データの保護(MUST)

データの削除

解約したユーザーのデータは必ず削除できなくてはなりません。サブシステムのデータなど、サイズが小さいしバッチ作るのが面倒だから削除しなくてもいいや、とは思わず、必ずすべて削除するようにしましょう。解約から削除されるまでの期間も明確にしておきます。必要に応じて、ダウンロードや記録媒体などによってデータを返却できるしくみを用意します。

個人情報の取得と第三者提供

個人情報を取得する場合は、利用目的をプライバシーポリシー等に明記し、確実に保護することが求められます。あとで必要になるかもしれないからとユーザーに関するいろんな情報を取得したくなるかもしれませんが、漏洩した場合のリスクが大きいので必要最低限の個人情報のみ取得するようにしましょう。また個人情報は外部サービスなどの第三者に送信しないようにします。

セキュリティリスクのある機能の制限(SHOULD)

機密情報が外部に漏洩する恐れのある機能については、システム管理者が機能の使用可否を設定できるようにします。気をつけていないと忘れがちですが、例えば以下のような機能は使用のオン、オフを切り替えられるようにします。

• メール送信機能
• 外部サービスとの連携機能
• インターネットへの公開機能、共有機能

第三者機関による脆弱性検査(SHOULD)

セキュリティ専門ベンダーによる有料の脆弱性検査を受けることで、潜在している問題を発見し、攻撃リスクを低減することができます。

第三者による認証(MAY)

医療や官公庁向けなど、高度なセキュリティ対策を求められるサービスにおいては、第三者による認証が必要となるケースがあります。認証の種類としては、プライバシーマーク（Pマーク）またはISMS（ISO/IEC 27001）の取得を求められることが多いようです。

おわりに

セキュリティ対策はあとから根本的に実施するのが難しい場合があり、エンジニアにしてみると最初から知っていればよかったと後で思うことも多いです。Webサービスの開発運用を行うみなさまに、この記事が参考になれば幸いです。