アプリケーションの基本
前回は、PCやスマートフォンなど端末側のセキュリティ対策について整理しました。
今回は、その端末からアクセスする「アプリケーション」側のセキュリティについて考えてみます。
クライアントサーバー方式（Client-Server Model）で考えると、前回がクライアント側、今回はサーバ側の話ともいえるでしょう。
やることは多岐にわたりますが、ひとつずつ紐解いていきましょう。
①アプリケーションにおける防御
まず大前提として、「あなたが管理しているアプリケーションはどのタイプか？」という問題があります。
オンプレでアプリもスクラッチ開発（オーダーメイド）という場合、インフラ部分のパッチ適用や脆弱性対策、ハードウェアの故障対応等も入ってきます。（図の一番左）
一方でSaaSの場合は、インフラやアプリケーション自体の管理はサービス提供事業者が行います。
そのため利用者側は、権限管理やログ監視、データ保護といった利用者責任の範囲が管理対象となります。
今回はスクラッチ開発におけるアプリの防御を考えていきたいと思います。
セキュアコーディング
スクラッチ開発の場合、開発段階からセキュリティを考慮し、脆弱性を作り込まないようにする必要があります。
セキュアコーディングによって防ぎたい代表的な攻撃は以下です。
SQLインジェクション（データベース不正操作）
クロスサイトスクリプティング（XSS）（スクリプト埋め込み）
コマンドインジェクション（サーバ不正操作）
不正なファイルアップロード（マルウェア設置）
端末やネットワークの対策をどれだけ行っても、本体に脆弱性があったら元も子もありません。
セキュアコーディングを意識して、それに伴ったコードレビュー。
このあたりはAIを活用していくことも検討する必要があります。
第三者による確認
自分で作ったアプリを自分で「大丈夫です！」といってもあまり信頼されないので、可能な限り第三者による確認を入れた方が良いでしょう。
脆弱性診断でアプリの脆弱性や設定不備の確認し、ペネトレーションテストで実際の攻撃手法による検証を行います。
そこで見つかった不具合を定期的に改善していくサイクルも重要になります。
利用者・管理者のアクセス制御
どれだけセキュアなアプリでも、アクセス制御がガバガバだったら不安が残ります。
最小権限の原則に則れるようなロールベースアクセス制御（RBAC）を実装し、管理者を制限できる仕組みを作ります。
また、APIを公開する場合は、APIアクセス制御も必要です。
昨今のAPIを悪用した情報漏えいや不正アクセスも増えており、このあたりの対策は重要性が高まっています。
アプリケーションを外側から保護
アプリの中のセキュリティ防御を整えたら、最後に外側からの攻撃に対する防御を実施します。
WAFでWebアプリケーションを狙った攻撃を遮断し、API GatewayでAPIへのアクセスを適切に制御します。
Bot対策によって自動化された不正アクセスを防ぎ、レート制限（Rate Limit）によって過剰なリクエストやサービス妨害攻撃（DoS攻撃）の影響を軽減します。
② アプリケーションにおける検知
それでもやっぱり、脆弱性を発見されたり、設定ミスを見つけられて攻撃を受けてしまうことがあります。
その場合、複数の監視手法で検知していくのが一般的でしょう。
アクセスログ監視で、ログイン失敗の急増や異常なアクセス頻度を見つけ、不正アクセスの兆候を検知します。
不審なIPアドレスからのアクセスや通常とは異なる時間帯の操作を分析することで、不正利用の早期発見につなげます。
アプリケーションログ監視では、エラーの急増や想定外の例外発生を発見して、システムの異常を検知します。
不正なAPI呼び出しやデータ取得量の異常増加を分析することで、攻撃や情報漏えいの兆候を発見します。
セキュリティイベント監視で、WAFアラートや脆弱性攻撃の試行を見つけて、アプリケーションへの攻撃を早期に検知します。
アカウント乗っ取りやAPI悪用の兆候を把握し、被害拡大の防止につなげます。
③ アプリケーションにおける対応
攻撃を受けた形跡を検知したら、インシデント対応を行います。
検知した内容によって対応は変わりますが、被害を最小限に抑えるならシナリオ毎のインシデント対応マニュアルを作り、ガバナンスを意識した上で最速で対処が完了するような実行権限設定をします。
例：管理者権限の乗っ取り
管理者アカウントが乗っ取られた疑いがある場合は、まず被害拡大を防ぐことを優先します。
対象アカウントを一時停止し、不正利用を直ちに停止します。
また、関係者に対して強制的なパスワード変更を実施し、認証情報が漏えいしていた場合でも再利用できない状態にします。
さらに、現在有効なセッションを無効化して、攻撃者がログイン済みの状態を維持できないようにします。
APIキーが利用されている場合はキーを失効させ、不正なAPI利用を停止します。
その後、ログを分析して影響範囲や侵入経路を調査し、必要に応じて追加の対策を実施します。
例：外部からの攻撃
外部からの攻撃が確認された場合は、まず攻撃元を特定し、被害拡大の防止を優先します。
攻撃元のIPアドレスを遮断するとともに、WAFのルールを追加して同種の攻撃を自動的にブロックできるようにします。
また、自動化された攻撃が確認された場合は、Bot対策やレート制限を強化し、不正アクセスを抑制します。
被害が拡大する恐れがある場合は、対象となっている機能やAPIを一時的に停止し、安全を確保しながら原因調査と復旧作業を進めます。
④ アプリケーションにおける復旧
インシデント発生後はログ解析や攻撃経路の特定を行い、原因を調査します。
影響範囲を確認した上で、システムやデータを安全な状態へ復旧していきましょう。
脆弱性の修正
原因調査によって特定された脆弱性や設定不備を修正し、同様の攻撃が再発しないよう対策を実施します。
アプリケーションの不具合に対してはソフトウェアを修正し、脆弱性が報告されているライブラリは安全なバージョンへアップデートします。
必要に応じてセキュリティ設定を見直してシステムの安全性を回復します。
データの復旧
インシデントによってデータが失われたり改ざんされたりした場合は、正常な状態への復旧を行います。
必要に応じてバックアップからデータを復元し、改ざんされたデータを修復します。
最近ではバックアップデータまで改ざんされているケースがあるため、3-2-1-1-0ルールに則ったバックアップを取得しておく重要度が高まっています。
3-2-1-1-0ルールとは、3つのコピー、２つの異なる媒体、１つはオフサイトに、１つは隔離などで改ざん防止して、リストア時にエラーが０であることを確認するという手法です。
復旧後はデータの整合性を確認し、システムが正しく利用できる状態に戻っていることを検証します。
再発防止
インシデントの原因や対応内容を踏まえ、同様の事象が再発しないよう対策を実施します。
開発プロセスを改善して脆弱性の作り込みを防ぐとともに、新たな監視ルールを追加して異常を早期に検知できるようにします。
セキュリティテストを強化し、必要に応じて運用ルールを見直すことも、組織全体のセキュリティレベル向上につながります。
システムは必ずしも「侵入されない」ことを目指すのではなく、「侵入されても被害を最小化し、素早く復旧できる状態」を目指す必要があります。
