【AWS】サイバー攻撃とセキュリティ

こんにちはえじまです

2023年6月23日にAWS Dev Dayに参加してきました

Summitに参加してきたときも思いましたが、とてもモチベーションが上がりましたので、もしまだ参加したことがないよという方は、次回の参加をお勧めします

今回参加したセッションにおいて学んだなかで、OWSPという言葉がでてきましたので、その内容と、セキュリティやサイバー攻撃について帰宅してから調べてみました

OWSP TOP 10とは？

OWASP Top 10は、Webアプリケーション・セキュリティに関する最も重大な10のリスクについてを、協力企業様からの情報をもとに数年に一度ランキング化しているものです
公式サイト

TOP10概要

セッションの内容として興味深かったのが、技術の進歩によって、SQL InjectionやOS Command Injectionといった脅威度が高く直接的な被害をもたらす脆弱性は発生しにくく、一方でロジックや設定ミスなどのプロダクトの特性に合わせ構築・実装を行う箇所で脆弱性が発生しやすくなっているというところでした
2017年版と2021年版ではかなり内容に差がありました

上昇トレンドと下降トレンド

• 2017年からランキングが上昇したもの

順位	内容
A01	アクセス制御の不備
A02	暗号化の失敗
A05	セキュリティに関わる設定の不備
A06	脆弱で古くなったコンポーネント
A09	セキュリティログとモニタリングの失敗

• 2017年からランキングが下降したもの

順位	内容
A03	インジェクション系攻撃
A07	識別と認証の失敗

パブリッククラウドを狙うサイバー攻撃の種類

トレンドが上昇しているもの

設定の不備を狙う攻撃

最近の侵害やデータ漏洩の多くは設定ミスに関連しているものが多いらしく、クラウドにおけるインシデントの最大60％が設定ミスに起因する

国内外問わず多くの企業で設定ミスに起因する情報漏洩が発生しているようです

AWSにおいては、ACLやセキュリティグループ、WAFの設定などがありますが、「セキュリティバイデザイン」と「シフトレフト」がとにかく大切なのだと再認識しました

• セキュリティバイデザイン
  企画や要件定義・設計段階で、セキュリティを考慮し対策や機能を盛り込むことで、実装段階でのセキュリティ観点での考慮事項の対策漏れやアーキテクチャレベルでの構築身を減らすことを目的とした設計の思想

• シフトレフト
  テストやレビューをできる限り前倒しし、設計や実装の不備やミスの発見を早期に行うため、クリティカルなバグを先に発見でき、手戻りを少なくする開発アプローチ

アプリケーションの脆弱性やコンテキストのずれの悪用

クラウド内部で動くアプリケーションの脆弱性を標的にした攻撃や利用するSaaSの設定や値がプロダクトのコンテキストからずれを悪用するなどし、不正に侵入するなど

偽ライブラリやサプライチェーンの汚染

• 偽ライブラリ
  攻撃者は、一見正規のライブラリや依存関係を提供しているように見せかけた、実際には悪意のあるコードを含んだ偽のライブラリを作成します。開発者やシステム管理者は、これを信頼して自分のプロジェクトやシステムに組み込んでしまう可能性があります

• サプライチェーンの汚染
  攻撃者は、信頼できるソフトウェアやサービスの開発者や供給業者のサプライチェーンに侵入し、悪意のあるコードやコンポーネントを差し込むことを試みます。これにより、本来は信頼性の高いソフトウェアや製品が攻撃者の意図する動作を行う可能性があります

その他トレンドが下降しているもの等

インジェクション系攻撃

インジェクション攻撃は、悪意のあるコードやコマンドを意図しない形でアプリケーションやシステムに挿入する攻撃手法です

主な目的は、攻撃者がシステムの制御を乗っ取ったり、機密情報を取得したり、不正な操作を行ったりすることです

インジェクション攻撃にはいくつか種類があります

1. SQLインジェクション
   Webアプリケーションがユーザーからの入力を不正に処理する場合、攻撃者はSQLコマンドを挿入してデータベースに対して意図しない操作を行うことができます。これにより、データベースの内容が漏洩したり、改ざんされたりする可能性があります

2. XSS（クロスサイトスクリプティング）
   攻撃者はWebページに悪意のあるスクリプトを挿入し、そのスクリプトが他のユーザーのブラウザ上で実行されるようにします
   これにより、攻撃者はセッションクッキーや個人情報などを盗み取ることができます

3. OSコマンドインジェクション
   アプリケーションがユーザーからの入力をOSのコマンドとして実行する場合、攻撃者は不正なコマンドを挿入し、システム上で任意のコマンドを実行できる可能性があります。

4. LDAPインジェクション
   LDAP（Lightweight Directory Access Protocol）を使用してアプリケーションがディレクトリサービスに接続する場合、攻撃者は不正なデータを挿入してディレクトリの情報を改ざんしたり、機密情報を取得したりできる可能性があります

XXE（XML External Entity）

XXE攻撃は、XMLパーサーの脆弱性を悪用して、外部のエンティティを読み込む攻撃手法です
XXE攻撃は、XMLベースのアプリケーションやシステムに対して影響を与える可能性があります

対策

偽ライブラリ対策

信頼性のあるソースからのライブラリやコンポーネントのみを使用し、セキュリティアップデートやパッチの適用を定期的に行うことが重要です

サプライチェーンの汚染への対策

ソフトウェアのサプライチェーンの監視や検証、セキュリティに関する最新の脅威情報の把握も重要な対策となります

インジェクション攻撃への対策

1. 入力データの検証と正規化

入力データを厳密に検証し、予期しないデータや特殊文字を拒否するためのフィルタリングを実施します
入力データを正規化することで、予期せぬ動作や脆弱性を引き起こす可能性を低減します

2. パラメータ化されたクエリまたはプリペアドステートメントの使用

SQLやLDAPなどのクエリを実行する際には、プレースホルダーを使用してパラメータ化されたクエリやプリペアドステートメントを使用します

3. エスケープ処理の適用

出力するデータを表示する際には、特殊文字をエスケープ処理して意図しないコード実行を防ぎます

4. 最小特権の原則の適用

アプリケーションやシステムには必要最小限の権限を与え、攻撃者が悪用できる余地を最小限に抑える必要があります
アクセス制御を適切に設定し、ユーザーに与えられる権限を制限します

XXE（XML External Entity）への対策

1. 外部エンティティの解析と展開の禁止
   XMLパーサーの設定や構成を調整し、外部エンティティの解析や展開を禁止します
   一般的には、DTD（Document Type Definition）の処理を無効化するなどの手段があります

2. ホワイトリストの使用
   受け入れられるエンティティを明示的に指定するホワイトリストを作成します
   信頼できるエンティティのみを許可し、それ以外のエンティティの使用を制限します

3. セキュリティアップデートの適用
   使用しているXMLパーサーや関連ライブラリの最新バージョンやセキュリティパッチを適用します
   これにより、既知のXXE脆弱性が修正され、攻撃のリスクを軽減できます

4. 強固な入力検証
   XMLデータの入力を厳密に検証し、信頼できないデータをフィルタリングします
   入力データのパターンや予想される構造を確認し、異常なデータを拒否します

5. アクセス制御と最小特権の原則
   システムやアプリケーションのアクセス制御を強化し、ユーザーに与えられる権限を制限します
   必要な権限だけを与え、不要な権限を排除することで、攻撃範囲を狭めます

まとめ

私は主にインフラを仕事としますが、設計・構築は今後も進歩する技術の中でより大切になっていきます

人間なので絶対はありませんが、少しでもヒューマンエラーや設計上のミス等を減らすことが、一番のセキュリティ対策になるかと感じました

そのためにももっと知識をつけ、チームで協力することを常に意識していきたいと思っております