タグ付けされた質問 セキュリティ、アイデンティティ、コンプライアンス
コンテンツの言語: 日本語
並べ替え 最新
以下に記載されている質問と回答を閲覧したり、フィルタリングして並べ替えて結果を絞り込んだりできます。
現状以下のようなアーキテクチャの認証APIがあります
[aws cloud front] -> [aws waf] -> [aws alb] -> [(自前の認証API)aws ecs] -> [RDS]
上記、自前の認証APIへの攻撃を検知する方法を模索しているのですが、本ケースにマッチするようなサービス、サービスの組み合わせはありますでしょうか？（WAFで防げるよということであれば、その辺りの詳細もご教示いただけると幸いです）
検知したいのは以下のような攻撃のケースです。
* 同一アクセス元IPアドレスから複数ユーザに対するアクセス試行
* 通常とは大きく地理的に異なる位置からのユーザに対するアクセス試行
認証のURIは全ユーザで同じで、ユーザのIDはpostメソッドのbodyに含まれています。
上記が必要になった背景として、SIEMの導入を検討しており、SplunkとAWSサービス群での比較を行っています。
現状Open Searchでアーキテクチャの各コンポーネントのログをとれているのですが、Open Searchでこのようなケースを検出するQueryの書き方もわからず、手詰まり状態となっています。
理想は自動で検知されてアラートが上がることですが、ログから分析して兆候を検知できればOKな状態です。
アカウントに登録しているIAMユーザーについて、退任者のユーザーの登録管理方法を検討しています。
退任者のユーザーは、物理削除か、非アクティブ化（いわゆる論理削除）のどちらかの対応になるかと考えているのですが、それぞれのメリット、デメリットが整理しきれていないように思います。
また、CloudTrailの活用を前提に、物理削除を行った場合、管理上失われると良くない情報がなくなるかどうかわからず、苦慮しています。
オンプレミスでは論理削除が一般的ですが、AWSではどちらが主流なのか気になっています。
今のところ、以下のように検討しています。
前提
1. 運用の方針として、運用担当者のIAMユーザーには、（非アクティブ化以外の）ポリシーをアタッチしない。
2. 権限付与は、必要なポリシーをアタッチしたユーザーグループに追加することによって実現する。
3. 権限剥奪は、ユーザーグループから削除することによって実現する。
4. 各種の操作は、誤操作を排除するため可能な限りCLIで行う。
物理削除のメリット
1. 不要なアカウントが消されているので、IAMユーザーの棚卸に手間がかからない。
物理削除のデメリット
1. 削除後には、CloudTrail以外で追跡することができない。
2. 退任者が再び着任した際に、登録作業をはじめからやり直す必要がある。
非アクティブ化のメリット
1. CloudTrail以外で追跡することができる。
2. 退任者が再び着任した際に、登録作業をある程度省略できる。
非アクティブ化のデメリット
1. 不要なアカウントが残っているので、IAMユーザーの棚卸に手間がかかる。
2. 非アクティブ化のためのポリシーを管理しなければならない。
社外秘の情報を持つPCからAWSマネジメントコンソールにログインする場合、
我々が管理するアカウントは厳密な権限分離とアクセスを許可する端末の制御が行われており、またアクセス先もドメインレベルの制御でhttps://aws.amazon.com/への接続のみを許可しています。
しかし例えば悪意のあるユーザーが社外秘の情報を持つPCから、事前に社外で作成しておいた全く関係の無いアカウントを用いてログインし、
オブジェクトストレージなどを利用し社外にデータを持ち出すことが可能だと考えています。
これを防ぐにはどのような構成が取れますでしょうか？