Webアプリケーションのセキュリティ基礎
■第5話：セキュアなデプロイとモニタリング
（最終更新日：2023.10.22）
（絵が小さい場合はスマホを横に）
「セキュアな状態を保ちたい」
Webサービスを運用する立場であるなら、なるべくセキュアなサービスを提供したいはずだ。
前項までで、アプリケーションレベルでの脅威への対応、セキュアな環境というものを説明した。
今回は、デプロイ時や通信、ログ監視などのサーバー側での対応について説明したいと思う。
１.セキュアなデプロイ環境の構築
セキュアなデプロイ環境として、まずはCI/CD（継続的インテグレーション/継続的デリバリー）が挙げられる。
テストが適切に書かれていれば、自動的にテストされ、安全な環境にコードがデプロイされる。
次に、最小権限の原則が挙げられる。アクセスが必要なスタッフのみ、デプロイ権限を持つようにする。
容易に権限を付与しないことで、不正を起こす確率を下げる。
更に、開発環境、ステージング環境、本番環境と環境を分離し、明確に役割を分けることで、確実なテストを行うことができる。
ステージング環境にアクセス出来る人も、最小権限の法則で限られた人で行う。
最後にセキュアなコンフィグレーションが挙げられる。
例えば、Djangoの場合、DEBUG モードの無効化、SECRET_KEYを限られたアクセスで管理、データベースのセキュアな設定、
CSRF対策の有効化、セキュリティヘッダーの使用、ALLOWED_HOSTS の適切な設定、パスワードの強度設定、最新のセキュリティパッチの適用などがある。
これらを適切に行うことで、 セキュアなデプロイ環境を構築できる。
権限を制限する（デプロイ）
２.HTTPSとその重要性
HTTPSはデータの通信を暗号化し、第三者によるデータの傍受を防ぐ。
HTTPSを使用するには、まずウェブサイトに対するドメインを取得し、SSL/TLS証明書を取得することが必要だ。
証明書を取得するには、認証局の証明が必要で、無料のLet's Encryptによる証明書と有料の証明書がある。
これらを使うことで、通信の暗号化（HTTPS化）はできる。
有料の証明書は、ドメイン認証、企業認証などと違いがあり、最も信頼性の高いものは値段も高く審査も厳しい。
ただし、その団体が確実に存在することを示し、偽サイトでないことを証明できる。
銀行などは、最も信頼性が高い、その企業がその場所に確かに存在することを証明できるEV認証を取得している。
安全な通信を行い、サイトの信頼性を証明するためにも、HTTPS化は必ず行おう。
また、当然ながらHTTPS化していないサイトよりもHTTPS化しているサイトの方がSEOの評価は高い。
SSL証明の種類
３.コンテンツセキュリティポリシー (CSP)
CSPは、ウェブページのセキュリティを向上させるためのブラウザ機能で、 ページが読み込むことができるコンテンツのソースを指定することができる。 これにより、クロスサイトスクリプティング (XSS) などの攻撃を防ぐのに役立つ。 以下は、CSPを使用して行う一般的な指示の例である。
CSPの使用例
これにより、読み込み元のドメインやAPIの接続先、Formの送り先、埋め込みフレームの読み込み元、
違反があった際のレポートの送り先などを指定することができる。
上記はCSPの基本的な使用例の一部である。
CSPには多くのディレクティブとオプションがあり、それらを組み合わせることで、さまざまな制約をウェブページに適用することができる。
CSPを導入する際には、設定の影響を十分に理解し、テストを行うことが重要だ。
４.ログの取得と監視
ログの管理は、システムの異常、追加したシステムの正常動作、不正アクセスの試みなどの情報を得るのに役立つ。
ファイル化して残すことで、後で状況を確認することもできるし、その記録を監視すれば、
ほぼリアルタイムに不正アクセスやセキュリティ違反を検知することができる。
ログには、個人情報（アカウント情報、財務情報、健康情報、業務情報など）を含めないようにすることも大事だ。
オンプレミス環境では、Unix系の標準的に使用されるもので、Syslog/Rsyslogなどがある。
監視はZabbixなどが有名である。
Zabbixを使うと、CPUやメモリの使用率、プロセス数、トラフィック量、DBのクエリ時間、仮想化環境のリソース使用量など、
ビジュアル化して見ることができる。
AWSでは、CloudWatch Logsで各種のリソースログ、CloudTrailでアカウントの活動やAPIコールの履歴、
OpenSearchによるリアルタイムでのログ監視、分析、視覚化などがある。
詳しくは、自分が使う環境のサービスを見てほしい。
大事なのは、見たいログ情報を記録し、いつでも見れる状態にすることである。
ログの監視
５.インシデント対応と障害復旧
セキュリティ対策や障害対策をしていたとしても、予期せぬトラブルによりインデントは発生するものである。
大事なことは、インシデントが発生した時でも、対応のプロセスや手順を計画し、想定しておくことである。
例えば停電が発生した場合は、損傷確認し、無停電電源装置の動作確認、
長時間停電の場合はシステムのシャットダウンなどを行うなどである。
加えて、バックアップを定期的に取得し、リストアできる状況を常に維持しておく。
動作確認のチェックリストと、インシデント対応に関する報告と改善をドキュメントにしておくことも大事だ。
サーバー管理に限らずだが、準備（事前）、対応（事中）、報告（事後）の適切な対応が求められる。
６.まとめ
今回、Webサービスのセキュアな運用方法について解説した。 セキュアとひとくくりに言っても、外部からの侵入によるものか、内部からの不正によるものか、災害によるものかで対応が異なる。 インシデントが起こった際、重要なのは事前準備で、停電の場合はこの対応、内部からの不正アクセスの場合はこの対応と、 起こりうる事態への対策を用意しておくことである。 この辺りも俗人化しないよう、ある程度マニュアルにして方法を残しておくと良い。 加えて、事後の報告、今後の対策という部分もドキュメントに残し、次起こったときは以前よりスムースに対応できるようにしておこう。
▼参考図書、サイト
安全なウェブサイトの作り方
情報処理推進機構
Zabbixとは
cybertrust
Amazon OpenSearch Serviceを利用したVMware Cloud on AWSワークロードのモニタリング
AWS