蚘事の目的

意倖ずややこしく奥深いAWS Certified Security – Specialty詊隓察策の䞭で

AWS若干ワカル自分も新しく知ったこずを蚘茉したした。

知らない範囲がどこかの炙り出し皋床にご掻甚ください

 

蚘事の察象者

SAAに受かったぐらいの人

SCSを受けたいず思っおいる人

1-5幎AWSに觊れおいる人

 

泚意

chatGPTず共にガヌッず曞いた蚘事なので、

蚘茉が少し叀くなっおいたり、単語の間違いがあるかもですが、

そちらはご愛嬌で。

あくたで知らない、匱い範囲のざっくりずした炙り出し皋床にご掻甚ください

皋よくマニアックなこずが曞かれおいるこずがこの蚘事の良いずころだず思いたす

 

芋出し

EC2関連

AWS Systems Manager

フォレンゞック分析

ずは犯眪捜査における分析や鑑識

Session Manager

新しい秘密鍵は䞍芁。

フォレンゞックAMI

フォレンゞックAMIはKMSによっお暗号化、耇合化されるのでポリシヌ暩限が必芁

EC2の䜿甚されおいるキヌペアを怜玢する楜な方法

aws ec2 describe-instances –query “Reservations[].Instances[].KeyName” | jq -r unique

Systems Manager Compliance

PatchBaselineOperationsに非準拠であるため、グラフで赀く衚瀺など、コンプラむアンスの衚瀺が可胜

REJECT トラフィック

「REJECTトラフィック」ずは、ネットワヌク通信においお、特定のデヌタパケットや接続リク゚ストが拒吊された状況を指したす。

ネットワヌクむンタヌフェヌス

プロミスキャスモヌドを備えおいない

EBS

EC2に入っおいるEBSの秘密鍵を玛倱したケヌス

authorized_keys の曎新は公開鍵で実斜する必芁がある

そしおその際むンスタンスは停止しおいる必芁がある

スナップショットの共有ルヌル

・スナップショットは、スナップショットが䜜成されたリヌゞョンに制限されたす。別のリヌゞョンずスナップショットを共有するには、そのリヌゞョンにスナップショットをコピヌしお、そのコピヌを共有したす。

・デフォルトの AWS マネヌゞドキヌ で暗号化されたスナップショットを共有するこずはできたせん。

共有できるのは、

カスタマヌマネヌゞド型キヌ

を䜿甚しお暗号化されたスナップショットだけです。

・暗号化されおいないスナップショットのみをパブリックに共有できたす。

・暗号化されたスナップショットを共有する堎合は、スナップショットの暗号化に䜿甚するカスタマヌマネヌゞド型キヌも共有する必芁がありたす。

プロキシEC2

送信元、送信先のチェックを無効化する必芁がある

ファむルシステム関連

S

S3 パブリックアクセスブロックはアカりントたたは S3 バケットに適甚される

バケットACL

バケットの個別のオブゞェクトぞのアクセス暩を調敎可胜なもの

コンプラむアンスモヌド

曞き蟌みは䞀回、読み蟌みは耇数を匷制できる

ガバナンスモヌド

少しコンプラむアンスモヌドが緩くなり、䞀郚ナヌザヌは䞊曞きなどが可胜

Glacier

S3暙準からGlacierに盎接デヌタを送信できる

24時間以内に移動をした方がいい。voltロックポリシヌに匕っかかる

Anonymous access granted

オブゞェクトACL

オブゞェクト ACL は、バケット所有者が所有しおいないオブゞェクトぞのアクセスを蚱可する唯䞀の方法です。

S3 オブゞェクト所有暩

–acl bucket-owner-full-controlを蚭定するこずで、バケットベヌスで所有暩蚭定が可胜。これであげおもらえたら完党な管理が可胜になる。

バッチオペレヌションゞョブ

オブゞェクトの暗号化が可胜

EFS

認蚌系

SSO

マネコンぞのアクセスを制限できる。

アプリケヌションの認蚌呚りは基本Cognitoを䜿甚するず良い

SCP

マネヌゞドSCP

これは倉曎できない

SCPはプリンシパルずNotPrincipal

をサポヌトしおいない

ACMCertifacate Manager

→AWS Certificate Manager は EC2 むンスタンスをサポヌトしおいない

RAM

サブネットの共有が可胜

CloudHSMのリ゜ヌスを盎接共有は難しい、サブネットやTGWが䞻に共有されるリ゜ヌス

AWS IAM Identity Center

AM Identity Center導入を怜蚎しおいお珟圚倖郚IdPを利甚しおいないのであれば、

デフォルトでIdentityCenterディレクトリがあるのでこれを利甚するこずが出来たす。

ルヌトナヌザヌ

ルヌトナヌザヌのパスワヌドは倉曎できない

ルヌトナヌザヌに暩限をアタッチメントもできない

AWSのABAC(タグに基づいたアクセス制埡)の蚭蚈/運甹

タグを甚いお、アクセス可胜なタグの蚭定を行うこずで暩限蚭定を行う圢

暩限セット　蚱可セット

AWS IAM Identity Center の 蚱可セット(Permission Set) は AWSアカりントぞのアクセス暩(など)を定矩するリ゜ヌス

アクセス暩限セットは、1 ぀たたは耇数の [IAM policies] (IAM ポリシヌ) のコレクションの定矩を䜜成および維持するテンプレヌト

IAM Access Analyzer

IAMの珟状の状況を芋お、意図しないアクセス暩限を保有しおいないかなどを怜蚌できるツヌル

過去ず今の違いを調べたいならconfigなどを䜿うのが良い

ロヌルの連鎖

ロヌルの連鎖は、AWS CLI たたは API を䜿甚しお 2 ぀目のロヌルを匕き受けるロヌルを䜿甚する堎合に発生したす。たずえば、User1 に RoleA ず RoleB を匕き受けるアクセス蚱可があるずしたす。たた、RoleA には RoleB を匕き受けるアクセス蚱可がありたす。RoleA API オペレヌションで User1 の長期的なナヌザヌ認蚌情報を䜿甚しお AssumeRole を匕き受けるこずができたす。このオペレヌションは RoleA の短期的な認蚌情報を返したす。ロヌルの連鎖を行うには、RoleA の短期認蚌情報を䜿甚しお RoleB を匕き受けたす。

マネコンではロヌルの連鎖はできない

Called Via

ポリシヌ暩限の蚭定で、DynamoDBやCloudFormationで蚭定可胜

䜕経由で呌び出された堎合の暩限ずしおの条件づけ

IAMポリシヌず境界ポリシヌの違い

IAMポリシヌず境界ポリシヌは、異なる甚途を持぀ため、䞀般的には別々に管理・適甚されたす。具䜓的には、以䞋のように扱いたす。

IAMポリシヌ

IAMポリシヌは、ナヌザヌ、グルヌプ、たたはロヌルに盎接アタッチされ、アクセス暩限を定矩するために䜿甚されたす。これらのポリシヌは独立したJSONドキュメントずしお䜜成され、AWSマネゞメントコン゜ヌル、AWS CLI、たたはAWS SDKを䜿甚しおIAM゚ンティティにアタッチされたす。

境界ポリシヌ

境界ポリシヌPermissions Boundaryは、IAMナヌザヌたたはロヌルに適甚される䞊限の暩限を定矩するために䜿甚されたす。境界ポリシヌも独立したJSONドキュメントずしお䜜成され、IAMナヌザヌやロヌルに察しお適甚されたす。

Pass Role暩限

Assume roleが特定のロヌルになる暩限

Pass Roleが特定のAWS サヌビスに IAM ロヌルをパスするための暩限

CloudFormationに暩限を枡すずきなど必芁

SAMLメタデヌタファむル

SAMLメタデヌタファむル 䞭身SAML (Security Assertion Markup Language) メタデヌタファむルは、XML圢匏で蚘述され、SAMLプロバむダヌIdPやSPの構成情報を提䟛したす。メタデヌタファむルには、プロバむダヌの゚ンドポむントURL、蚌明曞、サポヌトするプロトコルなどが含たれおいたす。

  • EntityDescriptor: メタデヌタのルヌト芁玠で、entityID属性はプロバむダヌの䞀意の識別子です。
  • IDPSSODescriptor: IdPIdentity Providerの情報を含む芁玠です。protocolSupportEnumeration属性はサポヌトするSAMLプロトコルを瀺したす。KeyDescriptor芁玠には眲名甚の蚌明曞が含たれ、SingleSignOnService芁玠にはSSOSingle Sign-Onサヌビスの゚ンドポむントが蚘述されおいたす。
  • SPSSODescriptor: SPService Providerの情報を含む芁玠です。こちらもprotocolSupportEnumeration属性でサポヌトするプロトコルが瀺され、KeyDescriptor芁玠には眲名甚の蚌明曞が含たれたす。AssertionConsumerService芁玠にはAssertionを受け取るサヌビスの゚ンドポむントが蚘述されおいたす。

このようなメタデヌタファむルを甚いるこずで、IdPずSP間の蚭定や信頌関係を確立するこずができたす。

VPC

VPCトラフィックミラヌリング

DNSク゚リログは保存されない

Route 53 リゟルバヌのDNSログ機胜の蚭定が有効

ADFS

ADFSはActive Directory Federation Servicesの略称

ADFSの構築手順

ADFSActive Directory Federation Servicesサヌバヌの構築は、IDおよびアクセス管理のために重芁です。以䞋は、ADFSサヌバヌを構築する際に行う基本的な操䜜手順です。

1. 前提条件の確認

  • Windows Server がむンストヌルされたマシン
  • ドメむンコントロヌラヌ ぞのアクセス
  • SSL蚌明曞 の準備

2. サヌバヌマネヌゞャヌの䜿甚

  1. ADFSの圹割远加
    • サヌバヌマネヌゞャヌを開き、「圹割ず機胜の远加」をクリック。
    • 「圹割ベヌスたたは機胜ベヌスのむンストヌル」を遞択し、むンストヌルするサヌバヌを遞択。
    • 「Active DirectoryフェデレヌションサヌビスADFS」の圹割を遞択し、必芁な機胜ずずもにむンストヌル。

3. ADFSの構成

  1. ADFS構成りィザヌドの起動
    • サヌバヌマネヌゞャヌで「通知」アむコンをクリックし、「ADFSの構成」を開始。
    • 「フェデレヌションサヌビスの構成」りィザヌドが起動するので、以䞋の手順に埓う。
  2. フェデレヌションサヌビスの構成
    • 新しいフェデレヌションサヌバヌファヌムの䜜成最初のADFSサヌバヌの堎合、新しいファヌムを䜜成したす。
    • SSL蚌明曞の指定事前に準備したSSL蚌明曞を指定したす。
    • サヌビスアカりントの指定フェデレヌションサヌビスに䜿甚するドメむンナヌザヌアカりントを指定したす。
    • 構成デヌタベヌスの指定WIDWindows Internal DatabaseかSQL Serverのいずれかを遞択したす。
  3. 構成の完了
    • 構成が完了したら、フェデレヌションサヌビスの゚ンドポむントにアクセスしお、正垞に動䜜しおいるこずを確認したす。

4. クラむアントアクセス蚭定

  • ADFS゚ンドポむントの公開必芁に応じお、ADFSの゚ンドポむントを倖郚からアクセスできるようにしたすリバヌスプロキシやWAPを䜿甚。

5. Relying Party Trust信頌関係の蚭定

  • リラむングパヌティヌトラストの远加ADFSを利甚しおサヌビスに認蚌を提䟛するための信頌関係を远加したす。

6. クレヌムプロバむダヌトラストの蚭定

  • 必芁に応じお、クレヌムプロバむダヌトラストを蚭定したす。

7. テストず怜蚌

  • 蚭定が完了したら、テストナヌザヌを䜿甚しおログむンを詊み、正しく機胜するか確認したす。

これらの手順を順に実行するこずで、ADFSサヌバヌを正しく構築し、IDおよびアクセス管理のために䜿甚するこずができたす。

AWSでのADFS cognito SAML Microsoft Active directoryを甚いた認蚌の構築方法

AWSでADFSActive Directory Federation ServicesずCognitoを䜿い、SAMLSecurity Assertion Markup Languageを通じおMicrosoft Active Directoryによる認蚌を構築する手順は以䞋の通りです。

前提条件

  1. AWSアカりント
  2. Active Directory環境ずADFSのセットアップ
  3. Cognito User Pool

手順

1. ADFSの蚭定

  1. Relying Party Trustの远加
    • ADFS管理コン゜ヌルを開き、「Relying Party Trusts」を遞択し、新しいRelying Party Trustを远加したす。
    • りィザヌドに埓っお以䞋の情報を入力したす。
      • フェデレヌションメタデヌタURLAWSのCognito User PoolのSAML゚ンドポむントのURL。
      • 蚌明曞AWSのCognito User Poolからダりンロヌドした蚌明曞。
    • 他の蚭定はデフォルトのたた進めたす。
  2. Claim Issuance Policyの蚭定
    • Relying Party Trustsに察しおClaim Issuance Policyを蚭定したす。
    • 「Issuance Transform Rules」に新しいルヌルを远加したす。
      • Send LDAP Attributes as ClaimsLDAP属性をSAMLアサヌションずしお送信したす。
        • E-Mail-AddressesをName IDにマップしたす。

2. Amazon Cognitoの蚭定

  1. Cognito User Poolの䜜成
    • AWSコン゜ヌルにログむンし、Cognitoを開きたす。
    • 新しいUser Poolを䜜成し、名前を付けたす。
  2. Identity Providerの蚭定
    • User Pool内で「Federation」タブを遞択し、「Identity Providers」を遞択したす。
    • SAMLを遞択し、以䞋の情報を入力したす。
      • Metadata DocumentADFSのRelying Party Trustから取埗したメタデヌタドキュメント。
      • Attribute MappingSAMLアサヌションからの属性をCognitoのナヌザヌ属性にマッピングしたす。
  3. App Clientの蚭定
    • User Pool内で「App Clients」を遞択し、新しいクラむアントを䜜成したす。
    • クラむアント蚭定で、SAMLを蚱可する蚭定を有効にしたす。
  4. Domainの蚭定
    • User Pool内で「Domain Name」を遞択し、新しいドメむンを䜜成したす。
    • このドメむンはナヌザヌがログむンするための゚ンドポむントずなりたす。

3. テストず怜蚌

  1. ADFSからのログむンをテスト
    • 蚭定が正しく行われおいるかを確認するため、CognitoのドメむンURLにアクセスし、ADFSを通じおログむンを詊みたす。
    • 正しく蚭定されおいれば、ADFSのログむン画面が衚瀺され、認蚌埌にCognitoのUser Poolにリダむレクトされたす。
  2. ナヌザヌ属性の確認
    • ログむン埌、Cognitoのナヌザヌ属性が正しくマッピングされおいるこずを確認したす。

これで、AWSでADFSずCognitoを䜿ったSAML認蚌の蚭定が完了したす。問題が発生した堎合、蚭定の各ステップを再確認し、ADFSやCognitoのログを確認するこずでトラブルシュヌティングを行いたす。

httpセキュリティヘッダヌ

HTTPセキュリティヘッダヌは、りェブアプリケヌションのセキュリティを匷化するために䜿甚されるHTTPレスポンスヘッダヌです。これらのヘッダヌを䜿甚するこずで、ブラりザの動䜜を制埡し、様々な攻撃から保護するこずができたす

Strict-Transport-Security (HSTS)

X-Frame-Options

X-Content-Type-Options

などがある

VPC

VPCフロヌログのカスタム

宛先ず送信元のIPを入れたいずきは、既存のフロヌログを削陀し、srcipやtargetipを远加しおあげる必芁がある

Direct Connect

カスタマヌゲヌトりェむず仮想プラむベヌトゲヌトりェむの違い

カスタマヌゲヌトりェむCustomer Gateway, CGW

  • 圹割: オンプレミス物理的なデヌタセンタヌやオフィスネットワヌクに蚭眮されるデバむスたたは゜フトりェアで、クラりドネットワヌクずのVPN接続を確立する圹割を持ちたす。
  • 蚭眮堎所: ナヌザヌのオンプレミスネットワヌク内。
  • 接続の皮類: オンプレミスネットワヌクから仮想プラむベヌトゲヌトりェむVGWやトランゞットゲヌトりェむTGWぞのVPN接続を確立したす。
  • 構成: ナヌザヌが管理し、必芁なIPsec蚭定を行いたす。

仮想プラむベヌトゲヌトりェむVirtual Private Gateway, VGW

  • 圹割: AWSクラりド内のVPC仮想プラむベヌトクラりドにおけるVPN接続の終端ポむントずしお機胜したす。これは、AWSのネットワヌクむンフラの䞀郚ずしお提䟛されたす。
  • 蚭眮堎所: AWSクラりド内の特定のVPCにアタッチされたす。
  • 接続の皮類: 仮想プラむベヌトゲヌトりェむは、カスタマヌゲヌトりェむからのVPN接続を受け入れ、VPC内のリ゜ヌスず通信を可胜にしたす。
  • 構成: AWSマネゞメントコン゜ヌルやAPIを䜿甚しお蚭定したす。

具䜓的な違いのたずめ

  1. 蚭眮堎所:
    • CGW: オンプレミスネットワヌクに蚭眮。
    • VGW: AWSクラりド内のVPCにアタッチ。
  2. 管理責任:
    • CGW: ナヌザヌが管理し、蚭定。
    • VGW: AWSが提䟛し、管理。
  3. 圹割:
    • CGW: オンプレミスネットワヌクずクラりドネットワヌクを぀なぐVPN接続を確立。
    • VGW: クラりド内のVPCぞのVPN接続を受け入れ。

これにより、オンプレミスのネットワヌクずAWSクラりド内のネットワヌク間で安党な通信が確立され、デヌタ転送やリ゜ヌスの利甚が可胜ずなりたす。

EventBridge

ルヌトナヌザヌのアクセスを監芖可胜

セキュリティ関連

CloudTrail

組織レベルの CloudTrail有効化

を行うず、組織レベルでcloudtrailの蚭定など䞍芁ずなる。

AWS CloudTrailの「蚌跡」ず「組織の蚌跡」の違い

  • AWS CloudTrailの「蚌跡」ず「組織の蚌跡」の違いに぀いお

    CloudTrail蚌跡

    • 範囲: 単䞀のAWSアカりント内のアクティビティを監芖したす。
    • 䜜成ず管理: 各アカりントで個別に蚭定したす。個々のアカりント管理者が蚌跡を䜜成・管理したす。
    • コスト: 各アカりントごずに蚌跡の料金がかかりたす。
    • 利甚シナリオ: 単䞀のアカりントでのアクティビティの監査やセキュリティ監芖を行う堎合に適しおいたす。

    組織の蚌跡Organization Trail

    • 範囲: AWS Organizationsを䜿甚しお耇数のアカりントにたたがるアクティビティを監芖したす。
    • 䜜成ず管理: AWS Organizationsの管理アカりントが組織党䜓の蚌跡を蚭定し、管理したす。これにより、各アカりントで個別に蚌跡を蚭定する必芁がなくなりたす。
    • コスト: 組織党䜓での監芖ができるため、管理が簡玠化されるず共にコストの最適化が可胜です。ただし、蚌跡のコストは組織党䜓での利甚に基づきたす。
    • 利甚シナリオ: 耇数のアカりントを持぀倧芏暡な組織で、党䜓のアクティビティを䞀元的に監査・監芖したい堎合に適しおいたす。

    比范マトリクス

    特城 CloudTrail蚌跡 組織の蚌跡
    範囲 単䞀アカりント 耇数アカりント
    䜜成ず管理 各アカりントで個別に蚭定 管理アカりントが䞀括蚭定
    コスト アカりントごずに発生 組織党䜓で最適化可胜
    管理の容易さ アカりントごずに個別管理 䞀元管理で簡玠化
    適甚シナリオ 単䞀アカりントの監査・監芖 耇数アカりントを持぀組織の監査・監芖

CloudTrail が自動有効化されるようになった

CloudTrailがすべおのナヌザヌで自動的に7日間保管され、远跡できるようになりたした。

CloudTrail コン゜ヌル

ク゚リできるが、過去90日だけ

CloudTrailの敎合性の怜蚌

CloudTrailがhash倀を䜿い、改ざんの怜蚌を行うこずができる。

S3のデヌタ倉曎の有無の怜蚌に有効

AWS Network Firewall

WAFずの倧きな䜿い所の違いずしおは、アりトバりンド。

アりントバりンド通信のIPを制限したい時はこれがおすすめ。

毎週倉わるIPからの䞍正アクセスぞのアプロヌチには向いおいない。wafのレヌトベヌスが掚奚

NACL

以䞋のコマンドは172.31.16.139からデヌタが戻っおこないこずを指したもの数倀は適圓

2 1234567310 eni-1233a 203.0.113.33 172.31.16.222 0 0 1 4 336 1432917 143291 ACCEPT OK
2 1234567890 eni-12353a 172.31.16.222 203.0.113.33 0 0 1 4 336 1432917 143291 REJECT OK

この堎合、戻るずきにREJECTされおいるので、むンバりンドは受け入れられお、アりトバりンドがNGなこずがわかる。こういう堎合はNACLの蚭定をたず疑う

NACLはNACL単䜍でむンバりンドを蚱可できる

できない。ただしセキュリティグルヌプがセキュリティグルヌプAを蚱可するこずはできる。

1時ポヌト

よくあるのが、49152-65535の範囲、この範囲のアりトバりンドをNACLが開けおおかないず、クラむアントが動的ポヌトでアクセスしおきた時に察応できなくあんる

アりトバりンド蚭定䟋

120
---
Custom
---
TCP
---
49152-65535
---
0.0.0.0/0
---
蚱可
---

 

WAF

CAPTCHA

  • AWS WAF は、CAPTCHA パズルおよびサむレントチャレンゞを䜿甚しお、リク゚ストがボットから配信されたものではないこずを確認し、AWS WAF トヌクンを䜿甚しおクラむアントで最近成功した応答を远跡したす。

count

  • AWS WAF はリク゚ストをカりントしたすが、リク゚ストを蚱可するかブロックするかは決定したせん。これは非終了アクションです。AWS WAF がりェブ ACL の残りのルヌルの凊理を継続したす。定矩したルヌルでは、リク゚ストにカスタムヘッダヌを挿入し、他のルヌルで䞀臎するラベルを远加できたす。

リ゜ヌスポリシヌ

wafはリ゜ヌスポリシヌずいうものはない

AWS Audit Manager

具䜓的には、䞀般デヌタ保護芏則 (GDPR)、医療保険の携行ず責任に関する法埋 (HIPAA)、ペむメントカヌド業界デヌタセキュリティスタンダヌド (PCI DSS) ずいった、進化する耇雑な芏制やコンプラむアンス暙準に察応する為に継続的な自動゚ビデンス収集や゚ビデンスを基にしお監査レポヌトの䜜成が可胜

Amazon GuardDuty

ナヌザの操䜜や通信などのログを継続的にモニタリング、䞍審なサヌバヌずの通信や䞍正アクセスなど「悪意がある」ず疑われる挙動を、機械孊習を甚いお怜出したす

耇数アカりントの監芖

アカりントをリストにいれ、承認を受け入れるこずで耇数アカりントのアラヌトを䞭倮で怜知可胜

CloudTrailずの連携

Amazon GuardDuty は、CloudTrail からのログやむベントを利甚しお䟵入怜知システム (IDS) ずしお機胜したす。これにより、セキュリティ゚ンゞニアは、IDS の範囲を最倧化するこずができたす。たた、Amazon EventBridge ず Amazon Simple Notification Service (SNS) を䜿甚しお、怜出むベントを運甚チヌムが䜿甚する電子メヌル配信グルヌプに通知するこずができたす。

äž¡æ–¹ONにしおたら自動で怜知するずいう情報すらある

ThreatPurpose

ずは、攻撃型たたは朜圚的な攻撃型の脅嚁の䞻な目的に぀いおの説明です。GuardDuty 脅嚁の目的の䞀芧衚に぀いおは、次のセクションを参照しおください。

・圱響

この倀は、GuardDuty がアクティビティたたはアクティビティパタヌンを怜出するこずにより、ナヌザヌのシステムおよびデヌタを操䜜、䞭断、たたは砎壊しようずしおいるこずを瀺しおいたす。

・怜出

この倀は、GuardDuty がシステムおよび内郚ネットワヌクに関する知識を拡匵するために䜿甚する可胜性のあるアクティビティたたはアクティビティパタヌンを怜出したこずを瀺したす。

・動䜜

この倀は、GuardDutyは特定の AWS リ゜ヌスの確立されたベヌスラむンずは異なるアクティビティやアクティビティパタヌンを怜出したこずを瀺したす。

自動アヌカむブ

特定のナヌザヌやむベントなど、ログむン詊行で通知が䞍甚意に連続される堎合は、

特定のナヌザヌ名やむベントを自動アヌカむブしお通知しなくする蚭定が可胜

以䞋の3぀のサヌビスの違いAmazon GuardDuty AWS Security Hub AWS Control Tower

  • 内容

    AWS Control Tower

    • 目的: AWS環境の蚭定ず管理を簡玠化するためのサヌビス。
    • 機胜:
      • マルチアカりントAWS環境のセットアップずガバナンス。
      • 組織党䜓のベストプラクティスの適甚。
      • セキュリティ、運甚、コンプラむアンスのガヌドレヌル自動化されたルヌルずポリシヌの適甚。
      • 既存のアカりントや新芏アカりントを迅速に䜜成し、統制された方法で管理。

    AWS Security Hub

    • 目的: セキュリティアラヌトずセキュリティ態勢管理を統合するためのサヌビス。
    • 機胜:
      • AWS党䜓からセキュリティ関連のデヌタを収集、集玄し、ダッシュボヌドで衚瀺。
      • AWSの耇数のセキュリティサヌビスGuardDuty、Inspector、Macieなどやパヌトナヌ補品からの結果を䞀元管理。
      • セキュリティ基準CIS AWS Foundations Benchmarkなどに察するコンプラむアンスチェック。

    Amazon GuardDuty

    • 目的: 継続的な脅嚁怜出ずモニタリングを行うためのサヌビス。
    • 機胜:
      • AWSアカりント党䜓のログデヌタVPC Flow Logs、CloudTrail、DNSログなどを分析し、異垞なアクティビティや朜圚的な脅嚁を怜出。
      • マシンラヌニングずルヌルベヌスの怜出を利甚しお、セキュリティむンシデントを自動的に識別。
      • 怜出された脅嚁に関する詳现な情報ず掚奚アクションを提䟛。

    違いのたずめ

    • Control Tower: AWS環境党䜓のセットアップず管理を簡玠化し、ベストプラクティスの適甚を自動化する。
    • Security Hub: セキュリティ関連デヌタを統合し、セキュリティ態勢の可芖化ずコンプラむアンスチェックを提䟛する。
    • GuardDuty: ログデヌタを継続的に分析し、脅嚁怜出ずセキュリティむンシデントのモニタリングを行う。

    これらのサヌビスを組み合わせお䜿甚するこずで、AWS環境のセキュリティを匷化し、管理を効率化するこずができたす。

Amazon Detective

GuardDutyが有効になっおから48時間は経過しおいる必芁がある

限定された領域の監芖に有効、逆にVPC党䜓などではコストが嵩む懞念がある

Amazon GuardDutyずAmazon Detectiveの違い

  • Amazon GuardDutyずAmazon Detectiveの違い

    Amazon GuardDuty

    目的: Amazon GuardDuty は、AWS 環境の継続的な脅嚁怜出サヌビスです。脅嚁を怜出し、朜圚的なセキュリティ問題を特定するこずを目的ずしおいたす。

    䞻な機胜:

    • 脅嚁怜出: GuardDuty は、AWS CloudTrail、VPC Flow Logs、DNS ログなどのデヌタ゜ヌスから情報を収集し、機械孊習アルゎリズムやサヌドパヌティの脅嚁むンテリゞェンスを甚いお脅嚁を怜出したす。
    • 怜出結果の通知: 異垞な掻動や朜圚的な脅嚁が怜出されるず、アラヌトを生成したす。
    • 簡単な蚭定: GuardDuty は有効化が簡単で、远加のハヌドりェアや゜フトりェアのむンストヌルは䞍芁です。

    ナヌスケヌス:

    • 䞍正アクセスの怜出
    • 内郚および倖郚の攻撃の識別
    • セキュリティポリシヌの違反の発芋

    Amazon Detective

    目的: Amazon Detective は、セキュリティむンシデントの詳现な調査ず分析を支揎するサヌビスです。既に怜出された脅嚁や異垞な掻動の根本原因を特定し、詳现なむンサむトを提䟛するこずを目的ずしおいたす。

    䞻な機胜:

    • デヌタの自動収集ず分析: Detective は、AWS CloudTrail、Amazon VPC Flow Logs、Amazon GuardDuty の怜出結果からデヌタを自動的に収集し、グラフベヌスのデヌタモデリングを䜿甚しお盞関関係を分析したす。
    • 調査支揎: むンシデントのタむムラむンや圱響範囲を芖芚的に衚瀺し、疑わしいアクティビティの詳现な調査をサポヌトしたす。
    • むンサむトの提䟛: 耇雑なむンシデントを理解しやすくするための芖芚化ず分析ツヌルを提䟛したす。

    ナヌスケヌス:

    • セキュリティむンシデントの詳现な分析
    • 脅嚁の根本原因の特定
    • 調査プロセスの効率化

    䞻な違い

    • 目的: GuardDuty は䞻に脅嚁を怜出するためのサヌビスであるのに察し、Detective はその怜出結果をさらに詳现に調査し、分析するためのサヌビスです。
    • 機胜: GuardDuty は継続的なモニタリングずアラヌト生成を行い、Detective はむンシデントの詳现な調査ず因果関係の分析を行いたす。
    • ナヌスケヌス: GuardDuty はリアルタむムでの脅嚁怜出ずアラヌト通知に重点を眮いおおり、Detective は怜出されたむンシデントの深堀りず根本原因の解析に重点を眮いおいたす。

    䞡者は連携しお䜿甚するこずで、AWS 環境のセキュリティを匷化し、脅嚁の怜出から詳现な調査たで䞀貫したセキュリティ運甚を実珟できたす

Amazon Inspector

「ECR 基本スキャン」 は Amazon Inspector のような詳现な脆匱性分析やセキュリティ評䟡を提䟛しない

新しいメンバヌアカりントぞの自動スキャンが有効

EC2むンスタンスの脆匱性を発芋するのにも䟿利

セキュリティグルヌプ

異なるリヌゞョンにあるピア VPC のセキュリティグルヌプを参照するこずはできない。同じリヌゞョン内のみでしか参照での蚱可機胜は機胜したせん。

WAF

wafはリ゜ヌスポリシヌをサポヌトしない

AWS WAF (Web Application Firewall) でりェブACL (Web Access Control List) のログを Kinesis Data Firehose に送信する蚭定は、AWSコン゜ヌル内のAWS WAFの蚭定から行うこずができたす。

KMS

AWSマネヌゞドキヌはAWS管理のため、手動でのロヌテヌションができない

AWSマネヌゞドキヌは毎幎ロヌテヌションされる

デフォルトのAWSマネヌゞドキヌは自動ロヌテヌションができない

KMS デヌタキヌキャッシュを䜿甚するず、デヌタキヌを再利甚し、KMS 呌び出しを枛らし、コストを最適化できる

AWS Key Management Service (AWS KMS) のカスタマヌマネヌゞドキヌが「Disabled」に蚭定されおいる堎合、そのキヌは暗号化たたは埩号化の操䜜に䜿甚できたせん。

grant

aws kms create-grantで取埗可胜。

䞀時的な暩限を䞎える仕組み

kms:CreateGrant暩限が察応

4KB以䞊のデヌタを暗号化、耇合化するずき

はkms:GenerateDataKey たたは kms:Encrypt アクションに察しお GrantTokens を芁求する必芁がある

゚ンベロヌプ暗号化

キヌを暗号化し、それをさらに暗号化する2重暗号化の仕組み

ちょっず難解なので埌日もうちょい調査

暗号化コンテキスト

  • キヌず倀の䟋 
      "Condition": {
      "StringEquals": {
            "**kms:EncryptionContext:AppName**": "ExampleApp",
            "**kms:EncryptionContext:Version**": "1.0.24"
            
} } }

AWS Database Encryption SDKを甚いお、DynamoDBのデヌタを暗号化できたすか

  • はいできたす、以䞋がコヌド䟋 
    import boto3
import aws_encryption_sdk
from aws_encryption_sdk import CommitmentPolicy
from aws_encryption_sdk.keyrings.aws_kms import AwsKmsKeyring

# AWS KMSのCMKのARNを蚭定
key_arn = 'arn:aws:kms:your-region:your-account-id:key/your-key-id'

# DynamoDBクラむアントの䜜成
dynamodb = boto3.client('dynamodb', region_name='your-region')

# AWS KMS Keyringの䜜成
keyring = AwsKmsKeyring(generator_key_id=key_arn)

# 暗号化するデヌタ
data_to_encrypt = {
    'id': {'S': '123'},
    'name': {'S': 'John Doe'},
    'email': {'S': 'john.doe@example.com'}
}

# AWS Encryption SDKの暗号化
encrypted_data = {}
for key, value in data_to_encrypt.items():
    plaintext = value['S'].encode('utf-8')
    ciphertext, _ = aws_encryption_sdk.encrypt(source=plaintext, keyring=keyring)
    encrypted_data[key] = {'B': ciphertext}

# 暗号化されたデヌタをDynamoDBに保存
dynamodb.put_item(
    TableName='your-dynamodb-table',
    Item=encrypted_data
)

DynamoDBのコン゜ヌルから芋るず暗号化された圢で保存されおいたす。

ただし、DynamoDB 暗号化クラむアントを䜿うのが、dynamoDBに関しおは䞀番手軜

尚䞔぀䞍正なデヌタ倉曎も怜出できる

キヌポリシヌ

  • キヌポリシヌ䟋 
    {
    "Version": "2012-10-17",
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

キヌストアずキヌマテリアルのマトリクスに関しお、メリデリ敎理

キヌストアずキヌマテリアルのマトリクス

特城 デフォルトキヌストア カスタムキヌストア キヌマテリアルの有無
セットアップの容易さ 簡単にセットアップ可胜 蚭定が耇雑になるこずが倚い キヌマテリアルの有無に関わらずセットアップが必芁
運甚管理 管理が簡単 管理が耇雑 キヌマテリアルの生成ず管理が必芁
セキュリティ 暙準的なセキュリティ 高床なセキュリティ蚭定が可胜 キヌマテリアルがある堎合、より高いセキュリティ
コスト コストが䜎い カスタム゜リュヌションのためコストが高いこずが倚い キヌマテリアルの生成ず管理にコストがかかるこずがある
スケヌラビリティ スケヌラブル 蚭蚈次第でスケヌラブル キヌマテリアルの管理次第
カスタマむズ性 制限される 高いカスタマむズ性 キヌマテリアルがある堎合、柔軟にカスタマむズ可胜
互換性 䞀般的に高い 他システムずの互換性は蚭蚈次第 キヌマテリアルのフォヌマットに䟝存

カスタムキヌストアを䜿う堎合はCloudHSMが必芁ずなる。

デフォルトのキヌストアでもカスタマヌキヌのむンポヌトは可胜

たた、キヌの自動倱効期間の蚭定を行うずきは、自分でキヌマテリアルをむンポヌトしカスタマヌマネヌゞドキヌを䜜るこずで実珟可胜

KMSのラッピングキヌ　むンポヌトトヌクン　キヌマテリアルの関係性

  • 内容
    • ラッピングキヌ (Wrapping Key): ナヌザヌのキヌマテリアルを暗号化するために䜿甚される䞀時的な公開鍵。AWS KMSが提䟛したす。
    • むンポヌトトヌクン (Import Token): キヌマテリアルが正しいCMKに関連付けられおいるこずを確認するためのトヌクン。AWS KMSが提䟛したす。
    • キヌマテリアル (Key Material): ナヌザヌが独自に生成した暗号鍵デヌタで、CMKにむンポヌトされたす。

KMSにおいおカスタムキヌストアを䜿甚するメリット

カスタムキヌストアを䜿甚するず、HSMハヌドりェアセキュリティモゞュヌルを䜿甚しお暗号鍵を管理できたす。

Encryption Context

ざっくりいうず完党な暗号化

察象鍵暗号化単䜓では気付けないデヌタの改竄を防ぐ仕組み

AADに察応

䞀時的なキヌの䜿甚

Grantを䜜成するこずで実珟可胜

AWSのポリシヌのbool if exists ずboolの違い

  • Bool は、キヌが存圚しない堎合、条件は false ずなりアクセスは拒吊されたす。
  • BoolIfExists は、キヌが存圚しない堎合、条件は無芖され、デフォルトのアクセス蚱可たたは拒吊の蚭定に埓いたす。

BoolIfExistsを䜿甚したい堎面

もしキヌ自䜓がなくおもDenyしたい堎合に䜿う

䟋えばaws:MultiFactorAuthPresentをマストにしたい堎合、

boolでdenyだずMultiFactorAuthPresentのconditionが存圚しない堎合にdenyに行かない。

なのでBoolIfExistsである必芁がある。

キヌが存圚しなくおもtrueを返せるのがいいずころ。

Systems Manager パラメヌタストアのsecure stringずSecret Managerのパラメヌタでのメリットデメリット

  • 内容詳现

    AWS Systems Manager Parameter Store

    抂芁:

    • パラメヌタの管理およびストレヌゞサヌビス。
    • パラメヌタの皮類ずしおプレむンテキスト文字列、Secure String暗号化された文字列をサポヌト。
    • シヌクレットをKMSKey Management Serviceで暗号化。
    • IAMポリシヌを䜿っおアクセス制埡を管理。

    メリット:

    • コスト: 基本的に無料で、Secure Stringの堎合も少量のコストで利甚可胜。
    • 統合: SSM゚ヌゞェントを利甚するこずで、EC2むンスタンスやオンプレミスのサヌバヌずの統合が簡単。
    • バヌゞョン管理: パラメヌタのバヌゞョン管理が可胜。
    • アクセス制埡: IAMポリシヌを䜿っお柔軟にアクセス暩を蚭定できる。

    デメリット:

    • ロヌテヌション: 自動ロヌテヌション機胜がなく、手動で行う必芁がある。
    • シヌクレットの管理: 倧量のシヌクレットや耇雑なシヌクレット管理には向かない。

    AWS Secrets Manager

    抂芁:

    • デヌタベヌス認蚌情報、APIキヌ、その他のシヌクレット情報を安党に保存および管理するサヌビス。
    • シヌクレットの自動ロヌテヌション機胜があり、AWS Lambdaを利甚しおカスタムロヌテヌションも可胜。
    • デフォルトでKMSを䜿甚しおシヌクレットを暗号化。

    メリット:

    • 自動ロヌテヌション: シヌクレットの自動ロヌテヌションが可胜で、セキュリティを高める。
    • 管理の簡玠化: シヌクレットの管理が容易で、APIやコン゜ヌルから簡単にアクセスできる。
    • 通知機胜: シヌクレットのロヌテヌション時にSNSなどで通知が可胜。

    デメリット:

    • コスト: 䜿甚量に応じお远加コストが発生する。特に倧芏暡なシヌクレット管理の堎合にはコストが高くなる可胜性がある。
    • 耇雑性: 䜿い方が若干耇雑で、特にカスタムロヌテヌションの蚭定には技術的な知識が必芁。

    比范

    特城 Parameter Store Secrets Manager
    コスト 基本無料Secure Stringは少量のコスト 䜿甚量に応じお远加コストが発生
    ロヌテヌション 手動 自動ロヌテヌション機胜がある
    バヌゞョン管理 あり あり
    暗号化 KMSを䜿甚 KMSを䜿甚
    アクセス制埡 IAMポリシヌで管理 IAMポリシヌで管理
    管理の容易さ シンプルなシヌクレット管理向け 耇雑なシヌクレットや倧量のシヌクレット管理に適しおいる

    たずめ

    • 単玔なシヌクレット管理やコスト重芖の堎合は、AWS Systems Manager Parameter Storeが適しおいたす。
    • 自動ロヌテヌションや高床なシヌクレット管理が必芁な堎合は、AWS Secrets Managerが適しおいたす。

    遞択は、具䜓的なナヌスケヌスや必芁な機胜、予算に基づいお行うず良いでしょう。

Systems Manager でアクセスするには以䞋のような暩限が必芁

  • 暩限詳现 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:UpdateInstanceInformation",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "key-name"
        }
    ]
}

–pending-window-in-daysオプション

7日〜30日の削陀保留期間を指定できる

キヌの共有

デフォルトのマネヌゞドキヌは他アカりントず共有できないので、䜜成する必芁がある

暗号化したRDSのスナップショットを他アカりントず共有する時などに䜿甚

Security Hub

Security Hubを䜿甚するにはconfigが有効になっおいる必芁がある。

Config ずGuard dutyの違い

AWS ConfigずAmazon GuardDutyは、どちらもセキュリティずコンプラむアンスを支揎するためのAWSサヌビスですが、目的ず機胜が異なりたす。以䞋に䞡者の違いを説明したす。

AWS Config

目的

AWS Configは、AWSリ゜ヌスの蚭定を远跡、評䟡、監査、および蚘録するためのサヌビスです。リ゜ヌスの蚭定履歎を保持し、蚭定の倉曎を远跡するこずができたす。

䞻な機胜

  1. 蚭定倉曎の远跡: AWSリ゜ヌス䟋EC2、S3、IAMなどの蚭定倉曎を継続的に監芖し、その履歎を蚘録したす。
  2. コンプラむアンス評䟡: 蚭定ルヌルを定矩し、リ゜ヌスがこれらのルヌルに準拠しおいるかどうかを評䟡したす。
  3. 蚭定のスナップショット: 任意の時点でリ゜ヌスの蚭定状態をスナップショットずしお取埗し、保存したす。
  4. リ゜ヌス関係の可芖化: リ゜ヌス間の䟝存関係や関係を芖芚的に衚瀺したす。

䜿甚䟋

  • セキュリティポリシヌやベストプラクティスに察するリ゜ヌスのコンプラむアンスチェック
  • 倉曎履歎の監査
  • 蚭定倉曎の通知やアラヌト

Amazon GuardDuty

目的

Amazon GuardDutyは、AWSアカりントやワヌクロヌドのための脅嚁怜出サヌビスです。リアルタむムで悪意のある掻動や䞍正行為を怜出したす。

䞻な機胜

  1. 脅嚁むンテリゞェンス: 既知の悪意のあるIPアドレスやドメむン、攻撃パタヌンを利甚しお脅嚁を怜出したす。
  2. 機械孊習: 異垞な行動やパタヌンを怜出するために機械孊習アルゎリズムを䜿甚したす。
  3. クラりドTrail、VPCフロヌログ、DNSログの分析: これらのログを分析し、異垞や朜圚的な脅嚁を特定したす。
  4. アラヌト: 怜出された脅嚁に察するアラヌトを生成し、察応を促したす。

䜿甚䟋

  • 䞍正アクセスやアカりントの乗っ取りの怜出
  • マルりェアやデヌタ䟵害の監芖
  • ネットワヌクトラフィックの異垞怜出

比范たずめ

特城 AWS Config Amazon GuardDuty
䞻な目的 リ゜ヌスの蚭定倉曎ずコンプラむアンスの監芖 脅嚁の怜出ずセキュリティの監芖
監芖察象 AWSリ゜ヌスの蚭定 AWSアカりントやワヌクロヌドの脅嚁
䞻な機胜 蚭定履歎、コンプラむアンス評䟡、蚭定のスナップショット 脅嚁むンテリゞェンス、機械孊習、ログ分析
䜿甚䟋 リ゜ヌス蚭定の監査、コンプラむアンスチェック 䞍正アクセス怜出、マルりェア監芖

これらのサヌビスは、盞互補完的に䜿甚するこずで、セキュリティずコンプラむアンスの䞡面でより匷力なAWS環境を構築するこずができたす。

CloudWatch

゚ヌゞェントを入れるこずで、CloudWatch Logsにログを蓄積できる

詳现なCloudWatch のメトリクス

Amazon CloudWatch のメトリクスはモニタリングに特化しおおり、API のアクセスパタヌンを分析できない

CloudWatch ゚ヌゞェントずSSM゚ヌゞェントをEC2に入れた堎合の違い

CloudWatch ゚ヌゞェントずSSM ゚ヌゞェントは、䞡方ずも AWS の管理ず監芖を支揎するためのツヌルですが、それぞれ異なる目的ず機胜を持っおいたす。以䞋にその違いを説明したす。

CloudWatch ゚ヌゞェント

目的: 䞻にメトリクスずログの収集および送信を担圓したす。

機胜:

  1. メトリクスの収集: CPU、メモリ、ディスク䜿甚率、ネットワヌク統蚈などのシステムパフォヌマンスデヌタを収集したす。
  2. ログの収集: アプリケヌションログ、システムログ、カスタムログファむルを収集し、CloudWatch Logs に送信したす。
  3. カスタマむズ可胜: JSON 蚭定ファむルを䜿甚しお、収集するメトリクスやログの蚭定を詳现にカスタマむズできたす。

䜿甚䟋:

  • サヌバヌやアプリケヌションのパフォヌマンス監芖
  • ログの集䞭管理ず分析

SSM ゚ヌゞェント

目的: EC2 むンスタンスおよびオンプレミスサヌバヌの管理を簡玠化するための゚ヌゞェントです。

機胜:

  1. Run Command: むンスタンスに察しおコマンドをリモヌトで実行したす。
  2. パッチ管理: パッチ適甚を自動化し、むンスタンスのセキュリティずコンプラむアンスを維持したす。
  3. Session Manager: シェルアクセスを提䟛し、SSH や RDP の代替ずしお䜿甚できたす。
  4. Inventory: むンスタンスの゜フトりェアや構成情報を収集し、むンベントリずしお管理したす。
  5. State Manager: むンスタンスの蚭定を自動的に適甚および維持したす。

䜿甚䟋:

  • むンスタンスのリモヌト管理ず操䜜
  • むンスタンスのセキュリティパッチの適甚
  • システム構成の管理ず維持

たずめ

  • CloudWatch ゚ヌゞェントは䞻にモニタリングずログ管理に特化しおいたす。
  • SSM ゚ヌゞェントはリモヌト管理、パッチ適甚、構成管理などの幅広い管理機胜を提䟛したす。

CloudWatch Logs Insights

クラりドりォッチの情報をク゚リしお、䞭身を怜玢できるサヌビス

ちなみにAPIゲヌトりェむからs3ぞのログ出力機胜は基本サポヌトされおいない

メトリクスはAPIの䜿甚状況の分析には向いおいない

AWS Audit Manager

Audit Managerでは、CISベンチマヌクを初めずした様々なセキュリティ芏栌をフレヌムワヌクで管理し継続的に監芖するこずができたす。

CloudHSM

CloudHSMマネゞメントコン゜ヌルの呌び出し、CloudHSM API呌び出しはCloudTrailに蚘録される

AWS Config

IAMのキヌロヌテヌションの期間超過を怜出可胜

自動怜出オプションを甚いお、SystemManagerのランブックを起動可胜

リアルタむムのアラヌトにはマッチしおいないので、そういう時はCloudTrailからCloudWatch Logsのメトリクスフィルタヌなどを介しお実斜するのがよい

非準拠の構成

に察応する堎合は、Systems　Manager Automationなどをconfigず䜵甚し䜿甚するのが良い。

Proactiveモヌド

re:Invent2022でAWS Config Ruleに新しい評䟡モヌドずしお「Proactive」モヌドが远加されたした。これたではConfig Ruleに非準拠のAWSリ゜ヌスが䜜成、蚭定倉曎埌にCofigによるコンプラむアンスチェックが実斜されおいたしたが、この新しい評䟡モヌドにより事前にチェックするこずができるようになりたした。

AWS Config 適合パック (Conformance Packs)

組織の求めるconfigのルヌルをorganization配䞋のアカりントに適合できる仕組み

Config Aggregator

各アカりントからconfigの蚭定を吞い取るシステム

ログ自䜓ではなく蚭定のみ。

AWS Config Rules

以䞋のような圢でlambdaを実装しおカスタムルヌルを䜜れる

def evaluate_compliance(configuration_item):

KMS クラむアントの䜜成

kms_client = boto3.client(‘kms’)

DevOps関連

Elastic Beanstalk

s3ずアクセスできない時気にするこず

むンスタンスプロファむルがIAMロヌルに玐づいおいるか。

AWS CloudFormation

CloudFormation Guard

これを䜿うず、CloudFormation のYAMLテンプレヌトにコンプラむアンス違反やセキュリティ䞊の蚭定ミスがないかデプロむ前にチェックできる

倉曎セットずstackセットの違い

倉曎セット (Change Sets)

  1. 目的:
    • 倉曎セットは、CloudFormationスタックに察する倉曎を適甚する前にプレビュヌするための機胜

スタックセット (Stack Sets)

  1. 目的:
    • スタックセットは、耇数のAWSアカりントやリヌゞョンにわたっおスタックを䜜成、曎新、削陀するための機胜

耇数のアカりントやリヌゞョンに䞀貫したスタックを展開するこずができたす

AWS Service Catalog

AWS Service Catalogは組織ずしおのガバナンスが適甚された補品を、AWS利甚者であるナヌザヌ郚門が早く簡単に立ち䞊げる事ができるサヌビスです。

スタンプを抌すように統䞀的な環境を䜜成する事が出来る

serviceカタログに察し、ナヌザヌやポリシヌを指定しアクセス蚱可を出す

Service Catalogにおける制玄ずは

Service Catalogにおける制玄ずは、蚭定した補品単䜍に適甚されるルヌル

起動制玄

起動制玄ぱンドナヌザヌが補品を起動する時に、どのIAMロヌルの暩限を利甚しお起動するのかを指定する制玄です。もっず具䜓的に蚀えば、「補品を起動する時にService Catalogが匕き受けるIAMロヌルの指定」ずなりたす。

゚ンドナヌザヌの暩限に蚱可を䞎えたくないが、補品を起動させたいケヌスで掻躍する制玄です。

CloudFormation 動的な参照

Secrets Manager などからDBのアクセスパスワヌドを取埗する際などに䜿甚。

DB関連

<

h3>DynamoDB
https通信のみサポヌトしおいる

RDS

RDSを暗号化するには

スナップショットをコピヌプロセスの暗号化で暗号化する。

新しい暗号化キヌを䜜成し、それを操䜜甚の暗号化キヌずしお䜿甚する。

CloudFront

カスタムドメむンで認蚌および承認されたナヌザヌにコンテンツを安党に提䟛する手段ずしお、CloudFront 眲名付き URL を䜿甚できる

SecurityHeadersPolicy マネヌゞドレスポンスヘッダヌポリシヌは、AWS CloudFront を䜿甚しお䞭間者攻撃からりェブサむトを保護するセキュリティヘッダヌをレスポンスに远加する機胜がある

AWS CloudFrontのIP範囲

jsonで公開されおおり、定期的に曎新される。これを取埗するプログラムを蚭定するなどはある皋床䞀般的

CloudFrontのOAIの制限

CloudFrontのOAIはKMSずの䜵甚はできないので、lambda@edgeなどで暗号化のフォロヌをする必芁がある

 

Lambda@edge で オリゞンレスポンスのタむミング カスタムヘッダヌを぀けれる

぀けれる

 

ECR

ECRのリポゞトリポリシヌの䟋

特定のIAMロヌルに察する読み取り専甚アクセスの蚱可:

jsonコヌドをコピヌする
{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ECRReadOnlyRole"
      },
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ]
    }
  ]
}

その他

Elastic Load Balancer

Elastic Load Balancer のアクセスログはS3 バケットにしかストリヌミングされない

Application Load Balancer

ALBの優䜍性

具䜓的には、Network Load Balancer (NLB) は䞻に Layer 4(トランスポヌト局) の負荷分散に特化しおいたす。SSL/TLS のタヌミネヌションのような Layer 7(アプリケヌション局) の高床な機胜が求められる堎合、Application Load Balancer (ALB) の䜿甚が掚奚されたす。

APIゲヌトりェむ

REGIONAL

PRIVATE

がある。

PRIVATEは特定のVPCからのアクセスのみ蚱容する圢ずなる。

単語関連

サヌバヌサむドリク゚ストフォヌゞェリ (SSRF) 攻撃

サヌバヌが行うリク゚ストを攻撃者が停造する攻撃です。簡単に話すず攻撃者が脆匱性があるサヌバヌを利甚しお内郚のサヌバヌに攻撃リク゚ストを送る攻撃

むンスタンスメタデヌタサヌビス (IMDSv2) のバヌゞョン 2

IMDS v2を利甚しおメタデヌタを取埗するためにはPUTメ゜ッドで発絊しおもらったTOKENが必芁になるので攻撃の難易床が高くなり、より匷化されたセキュリティを構成できたす。

以䞋条件でもv2の制埡、刀別可胜。

これのよさはすでに皌働䞭のEC2むンスタンスに察しおでもこの条件で刀別されおいるこず

numericLessThan

ec2:RoleDelivery:2.0

むンスタンスメタデヌタは、ホスト名、むベント、およびセキュリティグルヌプなどでカテゎリ分けされたす。

AWS Glue DataBrew

databrew ずquicksightの違い

AWS Glue DataBrewずAmazon QuickSightは、デヌタの準備ず可芖化のために䜿甚されるツヌル

単玔にDataBrewはデヌタの倉換、敎圢ツヌルなので、たったく違う

リフトアンドシフト

は、クラりド環境ぞの移行戊略の぀です。

リフトアンドシフトでは、第段階ずしおクラりドぞ既存のアプリケヌションをそのたた移行し぀぀、第段階でアプリケヌションをクラりドぞ最適化しおいきたす。

EKS

Amazon Elastic Kubernetes Service (Amazon EKS) クラスタヌのコントロヌルプレヌンログは、デフォルトでは Amazon CloudWatch Logs に送信されたせん。ログを CloudWatch Logs に送信するには、Kubernetes API サヌバヌコンポヌネントログを各クラスタヌで個別に有効にする必芁がありたす。この蚭定により、CloudTrail の制玄にかかわらず、Kubernetes のむベントを CloudWatch で効果的に監芖するこずができたす。

Well Architected Tool

カスタムレンズ

以䞋のような定矩ファむル蚭定を行うこずで、コストやセキュリティを含めた監査を実行しおくれる


- pillars[] # 柱
  - questions[] # 質問
    - choices[] # ベストプラクティス(チェック項目)
        - 内容
        - helpfulResource # 画面右端に出す「䟿利なリ゜ヌス」欄
        - improvementPlan # リスクありず刀断した堎合に画面䞋に出す「改善蚈画」欄
        ....
    - riskRules[] リスク刀定条件
        - 条件(choicesのidで条件を蚘述) & リスク

Route 53

䜍眮的情報ルヌティングはアクセスを拒吊できるか

→あくたで䜍眮は優先づけなので、拒吊はできない、おすすめはCloudFrontで制限する圢

サブドメむンぞのDNSSEC登録時

芪ドメむンぞのDerigation signer登録が必芁

フォレンゞックずは

フォレンゞックは法科孊の䞀皮で、事故・事件の痕跡や蚌拠を調査しお原因究明を行うこずを指したす。調査の察象事故珟堎がコンピュヌタなどの堎合、デゞタル・フォレンゞックず呌ぶ方が正しいのですが省略されるこずもしばしばありたす。デゞタル・フォレンゞックでは䞻にコンピュヌタ、ネットワヌクなどのセキュリティ事故むンシデントや内郚䞍正行為などを調査解析しお事故原因や裁刀で取り扱う蚌拠の特定などを行いたす。分かりにくいので、ピンずこない堎合は名探偵コナンにでおくる鑑識のトメさんみたいなむメヌゞをもっおいただければず思いたす。

フォレンゞックIPアドレスからのアクセスを蚱可する理由

  1. 攻撃者の掻動監芖:
    • 犯眪者の掻動を監芖し、攻撃の手法やパタヌンを理解するために、攻撃者が利甚するIPアドレスからのアクセスをあえお蚱可したす。
    • これにより、攻撃者の行動を远跡し、詳现な調査や分析を行うこずができたす。

AWS IoT

wirelessDataAccess

IoTWirelessずの接続の暩限

Amazon OpenSearch Service

フルテキスト怜玢、構造化デヌタの怜玢、ネストされたオブゞェクトの怜玢

が可胜だが、䟋えば特定のIAMアクセスキヌのログを怜玢する時などはAthenaの方が良い

スクリプトク゚リなどもいるが、ちょっず調敎が必芁。

アカりント属性タグベヌスのアクセス制埡

問の解説を曞く

Trusted Advisor

掚奚されるリ゜ヌスの提案を行うサヌビス

察話型セッション

コマンドラむンなどのようなコマンド䞊での操䜜セッションのこず

ブレヌクグラスナヌザヌ

緊急アクセス甚管理者アカりント(Break Glass アカりント) ずは、普段利甚しおいる管理者アカりントが利甚できなくなった時など緊急時に䜿甚する管理者アカりント

RDS

DB暗号化

暗号化したDBを䜜るためにはスナップショットを甚いお、スナップショットの暗号化実斜を行う必芁がある。

スナップショットから暗号化したスナップショットをコピヌする圢ずなる。

 

远蚘

AWS Control Tower ず Security Hub ず GuardDuty の違い

AWS Control Tower

ナヌスケヌス

  • ログの䞀元管理を行い、cloudtrailで情報を1アカりントに集積する。
  • ルヌルに準拠しおいないリ゜ヌスやアカりントを䞀芧できるダッシュボヌドの提䟛

利甚可胜なすべおのリヌゞョンで CloudTrail を有効にし、それを防止するガヌドレヌル蚭定が可胜

S3 バケットぞのパブリック読み取りアクセスを䞍蚱可にする行為の怜出が可胜

Security Hub

抂芁

耇数のAWSセキュリティサヌビスGuardDuty、Inspector、Macieなどおよびサヌドパヌティのセキュリティツヌルからのセキュリティアラヌトずコンプラむアンスステヌタスを統合し、䞀元的なダッシュボヌドで提䟛

耇数のAWSアカりントの䞀元管理も可胜

ベストプラクティスやスコアの衚瀺も可胜

GuardDuty

自動で怜出を行なっおくれるサヌビス

䟋えば以䞋の怜出が可胜

  • 䞍審なサヌバヌ、IPアドレスずの通信を怜出
  • EC2むンスタンスがDoS攻撃の実行に利甚されおいる可胜性を怜出
  • 悪意ある既知のIPアドレスからのAPI呌び出しを怜出