セキュリティ診断で確認する項目

Satoshi Tajima

安心してサービスを運用するために、セキュリティ関連の設定や運用に問題がないかをチェックしておくのは重要です。
最近、そんなチェックする機会が増えてきたので分野ごとによく指摘する・注意して確認する項目をリストにしてみました。

チェックする方法は手動の場合もツールを使って自動化する場合もあるし、参照する情報もソースコードだったり実際にHTTPリクエストをかけてみた挙動だったり、サーバにログインしてみてコマンドを叩いたりと様々です。
それぞれの項目をどうチェックしてるかは別途個別の記事にしたい(いつか)

  • 全てに対応しなければならない というリストではありません。サービスや事業の要件次第です。
  • 逆に、 すべて対応すればセキュリティの問題はなくなる というリストでもありません。
  • リストは都度追加・削除・修正していく予定です。
  • 粒度や抽象度がバラバラですが、より多くの場面で経験したものは抽象的になっている傾向があります。
  • 順番は思いついた順です。重要度や優先度も要件次第だと思っているのであえて並び替えたりしていません。
  • このようなチェックをしてほしいサービス・事業がある方がいましたらメールやTwitter等でご相談ください。

Webアプリケーション

  • XSSの対策がされているか
  • CSRFの対策がされているか
  • SQL Injectionの対策がされているか
  • 重要な情報が、(Blindも含む) SQL Injectionだけで盗めてしまわないよう対策されているか
  • OSコマンドインジェクションが実行できそうな余地がないか
  • SSRFが実行できそうな余地がないか
  • ディレクトリトラバーサルが実行できそうな余地がないか
  • 外部からの入力値が適切にバリデーションされているか (アップロードされるファイル等も含む)
  • セキュリティ関連のレスポンスヘッダが適切に設定されているか
  • X-Forwarded-For ヘッダの取り扱いが適切か
  • パスワードが適切な手法でハッシュ化された状態で保存されているか
  • 意図しないHTTPメソッドでリクエストを処理していないか
  • 機微な情報をGETパラメータで送信していないか
  • 機微な情報をログに出力していないか
  • 機微な情報がブラウザやCDNにキャッシュされてしまわないか
  • ユーザがパスワードを変更する手段が提供されているか
  • ユーザがパスワードを紛失してしまった場合に再設定する手段が提供されているか
  • パスワードリセット等からサービス利用者のメールアドレス一覧を作成できてしまわないか
  • 認証・認可を回避して情報の表示や操作ができてしまわないか
  • 一定回数のログイン失敗でアカウントがロックされるようになっているか
  • ログアウト時にサーバーサイドでもセッション情報が破棄されているか
  • ログインセッションは適切な時間経過によって失効されるようになっているか
  • ユーザが既存のログインセッションを無効化する手段が提供されているか
  • 管理者用の画面が、無防備にインターネットに公開されてしまっていないか
  • メールに適切なSPF, DKIMの設定がされているか
  • ユーザ固有の情報がキャッシュされ、他のユーザから閲覧されててしまう可能性がないか
  • (AoSSLの場合) 平文で利用できてしまうエンドポイントはないか
  • 証明書, 中間証明書が適切に設定できているか
  • SSL/TLSのProtocol, Cipher Suiteが適切に設定されているか
  • ドメインのWhoisが適切に設定できているか
  • 利用している暗号のアルゴリズム・鍵の強度が適切か
  • 乱数の生成や、ランダムな選択が適切な手段で行えているか
  • ディレクトリインデックスが表示される設定になっていないか
  • ソースマップファイルが公開されていないか
  • .git/ 等の公開する意図のないファイルにアクセスできてしなわないか
  • MySQLサーバーとの接続に、 CLIENT_MULTI_STATEMENTS が指定されていないか
  • MySQL等のデータストアへの接続に、不必要に強い権限を持ったユーザを利用していないか
  • DDoSを受けたときの対応プランがあるか

スマートフォンアプリ

今の所スマートフォンアプリをチェックする機会がそれほど多くないのでここは内容が薄いです…

  • サーバーサイドとの通信は暗号化されているか
  • 重要/緊急な情報をユーザに通知する手段があるか
  • 改ざんされると困る重要なロジックをスマートフォンアプリ側で実行していないか
  • 機微な情報を適切なデータストアに保存しているか
  • AWSのシークレットアクセスキーのような閲覧されると困る情報をアプリ内にコーディングしていないか

OS/ミドルウェア

  • サーバー上のオペレーションの内容が保全され、誰の作業か特定できるようになっているか
  • 各種ファイルに適切なオーナー・グループ・パーミッションが設定されているか
  • 不必要に強い権限で起動しているプロセスがいないか
  • 安全でない可能性のあるDocker Imageを利用していないか
  • Docker Imageの中に機微な情報を埋め込んでしまっていないか
  • クリティカルな脆弱性の見つかっているカーネル・OS・ミドルウェアを利用していないか
  • バナー (バージョン情報) の外部公開を無効にしてあるか
  • 不必要なデーモン/プロセスが起動していないか
  • ログがサーバーの外部(S3等)に保全されるようになっているか
  • 不必要な野良ルートCA証明書がインストールされていないか
  • 必要に応じて素早くメモリやディスクの情報の保全を行う準備があるか
  • 必要に応じて新規構築した新環境に切り替えることができるか

AWS

  • Trusted Advisorに対応すべき警告がでていないか
  • CloudTrailが有効になっているか
  • AWS Configが有効になっているか
  • VPC FlowLogsが有効になっているか
  • Guard Dutyが有効になっているか
  • 安全でない可能性のあるAMIを利用していないか
  • ALB・CloudFront等のアクセスログが有効になっているか
  • EBS, S3, RDS等のストレージの有効化の設定が有効になっているか
  • S3に不必要な読み込み・書き込みの権限のついたバケットポリシーが設定されていないか
  • 不必要に権限の強いIAMユーザが存在していないか
  • 意図しない環境からAssume Roleされてしまう可能性のあるIAMロールが存在していないか
  • 不必要に広くポートが開放されているセキュリティグループが存在していないか
  • RDS/RedshiftのPublic Accessibleが不必要に有効になっていないか

ネットワーク

  • 不審な通信に気がつく仕組みがあるか
  • 不審な通信に気づいた場合にそれを詳しく調査する方法があるか
  • 不必要に外部公開されてしまっているポートがないか
  • 外部公開されているアプリケーションに既知の脆弱性がないか
  • SSH/Active Directory/LDAP等の認証に弱い強度のアカウントが存在しないか
  • 重要な通信が平文になっていないか
  • 無線LANが適切なプロトコル(現在ならWPA2-AES等)で運用されているか

その他

  • リポジトリ上に機微な情報が平文でコミットされていないか
  • TLS通信時に、証明書の検証をスキップしていないか
  • パスワード・パスフレーズ・シークレットトークンをデフォルト値のままにしていないか

以上です。
ここもみておくべきだろうというご意見は歓迎です。 ぜひご連絡ください。