作る前に読むセキュリティチェックシート対策集
企業向けのWebサービスを提供していると、顧客からセキュリティチェックシートに記入してくれという依頼を受けることがあります。まあこれが企業によって内容がまちまちだったりするので、回答に時間がかかりして負担になるわけです。で、営業から開発にこれ全部満たしてるよねと投げられて、へ、そんなの聞いてないからやってませんよとなります。ならばある程度、開発のほうもセキュリティチェックシートにどんな項目があるか知っておけば、事前に対策できるのではないかなと思い、これを書くことにしました。
セキュリティチェックシートの雛形はある？
「セキュリティチェックシート」で検索してみると、いろんなベンダーからセキュリティチェックシートが公開されています。それらの多くは、「経済産業省：クラウドサービス利用のための情報セキュリティマネジメントガイドライン」なるものに準拠してますよと書かれているのですが、そのガイドラインが2013年の策定と古いものであり、現在経済産業省のサイトからリンクされているページを見つけることはできませんでした（ファイルはこちらからダウンロードできます）。代わりに総務省から、2021年版「クラウドサービス提供における情報セキュリティ対策ガイドライン」が公開されているので、そちらをベースとし、各社が公開しているセキュリティチェックシートから項目を加えました。またセキュリティチェックシートには運用体制や運用ルール、インフラに関する項目も多いのですが、そういったものは除外しています。「クラウドサービス提供における情報セキュリティ対策ガイドライン」にはセキュリティチェックシートのテンプレートもあるので、合わせてそちらも参考にしてみてください。
パスワード管理
パスワードの管理機能について。管理者がユーザーのパスワードを設定する場合は、あとでユーザーが自分で変更できるようにしないといけません。あとはまあ、おなじみのやつですね。
- パスワードは利用者自身が設定する
- パスワードはハッシュ化して保存する
- 脆弱なパスワードの使用を禁止する（最小文字数を設定し、記号も使用可能とするなど）
- 変更時は以前登録したパスワードを利用できないようにする
アクセス制限/セッション管理
これも企業向けのシステムを作られている方ならおなじみの内容と思います。強制ログアウトは24時間くらいが一般的みたいです。同一アカウントへのセッション数制限は、個人的には要件次第かなという感じがします。
- 指定回数以上認証に失敗したユーザーはロックまたは一定時間認証できないようにする
- 接続元IPアドレスによりアクセスを制限できる
- デバイス認証やMACアドレスによりアクセスを制限できる
- 多要素認証やシングルサインオンを利用することができる
- ログイン後一定時間以上の操作がない場合にログアウトさせる
- 同じアカウントに同時にログインできるセッション数を制限する
時刻の同期
全OSで時刻の同期は必ずやりましょう。
ログ
一般的に、以下のような種類のログを記録します。どのログも不正アクセスや改ざんがなされないように、アクセス制御や暗号化などによる保護を行います。AWSの場合はアクセスログとシステムログは普通にCloudWatch Logsを使うことになると思います。監査ログは必要に応じてデータベースに持つなど検討してみてください。
監査（操作）ログ
ログイン履歴や、ユーザーの操作を記録するログを取得します。監査ログは管理画面などから、ユーザーに提供できるのが望ましいです。
アクセスログ
操作ログと似ていますがこちらはユーザーに提供せず、サービス提供者が運用上の目的で使用します。
システムログ
システムの例外処理やエラー、システム障害を記録します。
保存期間
監査（操作）ログは1年、それ以外は90日保存しておけばよいようです。
バックアップ
ファイルストレージやデータベースのデータは必ずバックアップを取得し、バックアップから復旧できることを確認します。これは障害や災害のためのバックアップなので、S3など多拠点に分散して冗長化されたクラウドストレージについては、特別なことをしなくても対応しているといっていいと思います。データベースについては必ず毎日バックアップを取りましょう。
通信の暗号化
利用者とサービスとの通信経路はすべて暗号化します。またSSL3.0、TLS1.0、TLS1.1 といった、安全性の低い暗号化方式の使用を禁止します。最近はこれらの暗号化方式にしか対応していないブラウザはないので、ALBやNginxなどでTLSv1.2 TLSv1.3だけを有効にすればよいです。
データベース/ファイルの暗号化
データベースについては標準の暗号化機能を利用します。MySQLは5.7で透過的データ暗号化（TDE）がサポートされています。有効化すると性能が10%悪くなる？ セキュリティチェックシート様が要求するなら犠牲は必要です。OracleやPostgreSQLなどのRDBMSでもデータ暗号化の機能があります。アップロードファイルについては、クラウドストレージを使うのがほとんどだと思います。S3だと標準で暗号化が有効になっています。自前で共有ストレージを作る場合はOSレベルでパーティションの暗号化などを行ってください。
データの削除
解約したユーザーのデータは必ず削除できなくてはなりません。サブシステムのデータなど、サイズが小さいしバッチ作るのが面倒だから削除しなくてもいいや、とは思わず、必ずすべて削除するようにしましょう。解約から削除されるまでの期間も明確にしておきます。必要に応じて、ダウンロードや記録媒体などによってデータを返却できるしくみを用意します。
不正アクセス防止対策
不正アクセス防止のために以下の対策を求められることが多いようです。
- ファイヤーウォールを導入して許可されたポートのみアクセス可能とする
- 脆弱性を悪用した攻撃を防止する
- DoS攻撃の対策を行う
1はさすがにポートフルオープンで公開する人はいないと思います。2はAWSならWAFを導入すれば問題ありません。自前でIPSやIDSを導入する方法もあります。3はWAFでレートベースのルールを導入する方法や、ボットからのアクセスを無効化する方法など、対策レベルによっていくつか方法があります。
稼働状況のモニタリングと障害検知
セキュリティインシデントや、障害をモニタリングして検知できるようにします。
- クラウドサービス及び、ネットワークに対するパフォーマンス監視
- 構成要素の死活監視・障害監視
- エラーの監視
- 不正アクセス・不正利用の監視
AWSの場合はCloudWatchでアラームを設定して監視します。問題を検知した場合は、メールやSlackに通知して、速やかに対応ができるようにします。サービス停止など重要な障害が発生した場合は、速やかにホームページやSNS、メールなどを使ってユーザーに連絡するようにしましょう。
個人情報の取得と第三者提供
個人情報を取得する場合は、利用目的をプライバシーポリシー等に明記し、確実に保護することが求められます。あとで必要になるかもしれないからとユーザーに関するいろんな情報を取得したくなるかもしれませんが、漏洩した場合のリスクが大きいので必要最低限の個人情報のみ取得するようにしましょう。また個人情報は外部サービスなどの第三者に送信しないようにします。
管理者権限や特権ユーティリティの制限
Webアプリケーションやワーカーのプロセスを管理者権限で実行しないようにします。また不要なサービスやデーモンを起動しないようにします。コンテナではUSERを指定してサービスを起動するようにしましょう。
セキュリティリスクのある機能の制限
機密情報が外部に漏洩する恐れのある機能については、システム管理者が機能の使用可否を設定できるようにします。気をつけていないと忘れがちですが、例えば以下のような機能は使用のオン、オフを切り替えられるようにします。
- メール送信機能
- 外部サービスとの連携機能
- インターネットへの公開機能、共有機能
おわりに
開発者にとってセキュリティチェックシートはとにかく書かずに済ませたいものですが、ユーザーの企業の立場に立って考えると、セキュリティリスクを少しでも減らすために必要なこともわかります。え？ こんなこと求められるのと後から気づくことも多いので、Webサービスの開発運用を行うみなさまに、この記事が参考になれば幸いです。
