© 2015 - 2024 Nowcast Inc. 認証認可の基礎からはじめる AWS IAM 徹底入門 2024/6/19 株式会社Finatextホールディングス 大野巧作　@Kevinrobot34 技育CAMPアカデミア 1

© 2015 - 2024 Nowcast Inc. アジェンダ / 本日のゴール アジェンダ 1. イントロ 2. 認証・認可の一般論 3. AWS IAM 徹底入門 4. 開発時のTips 2

© 2015 - 2024 Nowcast Inc. 3 1. イントロ

© 2015 - 2024 Nowcast Inc. 4 1. イントロ ● 名前：大野巧作 ○ 大体けびんと呼ばれています ○ X(旧Twitter) は @Kevinrobot34 ● 役職：Data Engineer / Data Platform Engineer @ Nowcast ○ POSデータのパイプライン作成・運用 ○ Snowflake x dbt x terraform な社内データ基盤構築・運用 ■ 右下のテックブログに詳細あります！ ○ 2020年卒の社会人５年目です 自己紹介

© 2015 - 2024 Nowcast Inc. 5 1. イントロ AWSでサービス・システムを開発する際に、認証認可の仕組みであるAWS IAM は避けては通れません。 ● サービスの開発をしたいのに権限周りのエラーにはまってしまいなかなかメインの開発に進めなかった ● よくわからないままとりあえず全ての権限をつけてエラーを回避した というような経験がある方も多いのではないでしょうか？ 認証認可のエラーで困ったことないですか？

© 2015 - 2024 Nowcast Inc. 6 1. イントロ クラウドを用いてシステムやサービスを開発する際には、 （実際にはもっと複雑ですが）簡略化すると以下のようなステップがあるでしょう。 ● ① クラウドインフラの用意 ● ② ネットワークの設定 ● ③ 認証・認可の設定 ● ④ 実際にサービスを開発して疎通させながらテスト といったステップがあると思います。 ④の実際のサービス開発にいくまでの道のりは意外と長いと思います。 また①〜③のことがわかっていないと、出てきたエラーに対処できないこともあるでしょう。 今回は③の認証認可を深堀り整理しておくことで、 今後皆さんが認証・認可である程度困らないようになってもらうことを目標としています。 今回で理解しきれなくても一度用語を聞いておくと後からキャッチアップもしやすくなると思うので、 辞書的な形でこの資料も使っていただければと思って用意しています。 認証認可の立ち位置

© 2015 - 2024 Nowcast Inc. 7 2. 認証認可の一般論

© 2015 - 2024 Nowcast Inc. 8 2. 認証認可の一般論 JIS Q 27000 で定義されている情報セキュリティ ● 情報セキュリティの３要素 ○ 機密性 / Confidentiality ■ 許可されていない人は情報にアクセスできないようになっていること、データが秘匿されていること ■ 関連技術：認証・認可、暗号化、など ○ 完全性 / Integrity ■ 情報が改竄されたり消去されたりせず、正確かつ完全に残っていること ■ 関連技術：ハッシュ、署名、メッセージ認証符号、など ○ 可用性 / Availability ■ 許可された人が望んだ時に情報にアクセスできるようになっていること ■ 関連技術：秘密分散、バックアップ ● あとから追加された要素 ○ 真正性 / Authenticity ○ 責任追跡性 / Accountability ○ 否認防止 / Non-repudiation ○ 信頼性 / Reliability 認証・認可は機密性を実現するために大事な技術 情報セキュリティと認証認可

© 2015 - 2024 Nowcast Inc. 9 2. 認証認可の一般論 多くの場合認証と認可は同時に行われるが、本質的には全然違うもの。これを意識しておくと良い。 ● 認証 / Authentication (Authn) ○ 個人やデバイスが本人（または本物）であることを確認すること ○ 多くのWebサービスでは「Webサービスのサーバーが、利用者に対して、ユーザーIDとパスワードの組み合わせて利用者本人 であることを確認する」という認証プロセスをとっている ● 認可 / Authorization (Authz) ○ 認証されたユーザーに何の権限を付与するかを決定すること ○ 特定のユーザーに対するアクセス権限管理をする機能・手続き ○ スマホに特定のアプリを入れた際に、位置情報・アドレス帳等どの情報まで アクセスを許可するか設定するのも認可の一つ。 認証とは？認可とは？ 『AWSの薄い本　IAMのマニアックな話』より

© 2015 - 2024 Nowcast Inc. 10 2. 認証認可の一般論 認証の仕方（本人の確認の仕方）もいくつか種類がある。 ● 知識認証 ○ パスワードなどその人だけが知っている知識を利用した認証 ○ 具体例：パスワード、アクセスキーなど ● 生体認証 ○ 指紋や静脈などの生体情報を利用した認証 ○ 具体例：iPhone や Mac の Touch ID / Face IDなど ● 所有物認証 ○ ワンタイムパスワード(OTP)生成器などのその人しか持っていないものを利用した認証 ○ 具体例：OTP、YubiKeyなど ○ SMSによる所有物認証も使われていることはあるが、SMSはセキュリティを考慮したサービスではなく送受信内容が傍受され るリスクがあるため、所有物認証に用いることは避けるべきとされている 認証の種類

© 2015 - 2024 Nowcast Inc. 11 2. 認証認可の一般論 ● 複数の種類の認証を組み合わせることで、セキュリティのレベルをあげることができ、昨今多くのサービスで推奨されている ● 2つ組み合わせる場合には２要素認証と呼ぶこともある ● 具体例：パスワードによる知識認証と、OTPによる所有物認証の二つを組み合わせる ○ もしパスワードが流出しても、スマホを持っていないとワンタイムパスワードが分からず悪用されるリスクが減る ● 似た単語として2段階認証があるが、知識認証を二回やるだけの場合は１要素での認証であり、それだとMFAではなく良くない 多要素認証 / MFA (Multi Factor Authentication) Step1: 知識認証 Step2: 所有物認証 Google Authenticator などの スマホアプリで生成された MFAコードを入力

© 2015 - 2024 Nowcast Inc. 13 2. 認証認可の一般論 認証情報には長期的なものと、一時的なものがある ● 長期的な認証情報 ○ その名の通り有効期限が数ヶ月などと長いものから、場合によっては有効期限がないような認証情報 ○ ユーザーが保存し適宜利用することになるため、管理が大変 ○ 具体例：IAM User のコンソールパスワード ● 一時的な認証情報 ○ その名の通り有効期限が非常に短く、数分から数時間で失効するような認証情報 ○ 一時的な認証情報はユーザー側で保存されることはなく、ユーザーのリクエストに応じて動的に生成する ○ 一度作った一時的な認証情報が失効してしまったら再度新しい一時的な認証情報を作ってもらう ■ 失効したものが再利用されることはない ○ 具体例：IAM Role が利用する一時的な認証情報 認証情報：長期的 vs. 一時的

© 2015 - 2024 Nowcast Inc. 14 2. 認証認可の一般論 認可の中で実際にどのようにアクセスを許可するか、それを管理する方法は様々ありアクセス制御モデルと呼ばれたりする。 代表的なものは以下。 ● 任意アクセス制御 / DAC (Discretionary Accecc Control) ● ロールベースアクセス制御 / RBAC (Role-Based Access Control) ● 属性ベースアクセス制御 / ABAC (Attribute-Based Access Control) AWSではRBACやABACが、SnowflakeではDAC+RBACが使われている。 アクセス制御モデル Snowflake: DAC+RBAC AWS: RBAC AWS: ABAC

© 2015 - 2024 Nowcast Inc. 15 2. 認証認可の一般論 認可の中で実際にどのようにアクセスを許可するか、それを管理する方法は様々ありアクセス制御モデルと呼ばれたりする。 代表的なものは以下。 ● 任意アクセス制御 / DAC (Discretionary Accecc Control) ○ アクセス対象のリソースには所有者がいる ○ 所有者が「そのリソースには誰がアクセスできるか」を設定する方式のこと ○ 具体例 ■ Linuxのファイルシステムのアクセス制御 ● ユーザー・グループが各ファイルを所有している ● chmodで所有者はアクセス権限(r/w/x)を設定できる ■ DBのアクセス制御 ● ユーザーがテーブルやUDFなどを所有している ● 所有者は grant 文などで各種権限を設定できる アクセス制御モデル - DAC SnowflakeのDACの部分 Ownerが適宜grantする

© 2015 - 2024 Nowcast Inc. 16 2. 認証認可の一般論 認可の中で実際にどのようにアクセスを許可するか、それを管理する方法は様々ありアクセス制御モデルと呼ばれたりする。 代表的なものは以下。 ● ロールベースアクセス制御 / RBAC (Role-Based Access Control) ○ ユーザーのロール（役割）に応じて権限を付与する方式のこと ○ 具体例 ■ AWS の IAM Role を役割ごとに作成し、ユーザーに権限を付与する ■ Google Cloud / Azure など主要クラウドでもメインで使われている ○ メリット　：シンプルで管理しやすい ○ デメリット：必要なロールが増えると複雑性が増加していく ● 属性ベースアクセス制御 / ABAC (Attribute-Based Access Control) ○ ユーザーやリソースの属性に応じて権限を付与する方式のこと ○ 具体例 ■ AWS のユーザーやリソースのタグ情報を用いて権限を付与する ○ メリット　：ロールやポリシーの数は少なくて済む（増えない） ○ デメリット：設計が難しい アクセス制御モデル - RBAC / ABAC

© 2015 - 2024 Nowcast Inc. 17 2. 認証認可の一般論 認証認可に関して良く知られているプラクティスとして以下があります。 ● 長期的認証情報と一時的な認証情報の両方の利用が可能な場合には一時的なものを利用するようにする ○ IAM User と IAM Role 両方で実現可能であれば IAM Role を利用する ○ 長期的な認証情報はなくすことはできないが、管理が大変なのでなるべく増えないような構成が良い ● ユーザーアカウントの認証にはMFAを必須とする ○ AWSでいうと具体的には IAM User / Root User ● アカウント・ユーザーを複数人で共有しない ○ 便利だからとユーザーアカウントを複数人で共有してはいけない ■ 多くの場合、サービスの利用規約に抵触する ■ ログのトレーサビリティが下がってしまう ● メンバーA/B/Cの三人が一つのユーザーアカウントXを共有していたとする ● Xのログを見た際に、どのメンバーが実施したのかが分からなくなる 認証認可のベストプラクティス

© 2015 - 2024 Nowcast Inc. 18 2. 認証認可の一般論 認証認可に関して良く知られているプラクティスとして以下があります。 ● 最小権限の原則 / Principle of least privilege ○ パスワードの流出などで権限が悪用されてしまう場合の影響を最小限にするために、 必要十分な範囲の権限だけ設定しましょうという原則 ○ 範囲は２つの方向がある ■ 定義的な最小性 ● 実際に利用する操作の権限だけを付与する、という考え方 ● 例えばデータの読み込み権限のみ必要な場合には書き込み権限などは付与しない ■ 時間的な最小性 ● 強い権限が必要なユースケースも存在するが、その権限が常に必要なことはほとんどない ● 実際に作業をする数時間の間だけ強い権限を付与する、という考え方 認証認可のベストプラクティス

© 2015 - 2024 Nowcast Inc. 19 3. AWS IAM 徹底入門

© 2015 - 2024 Nowcast Inc. 20 3. AWS IAM 徹底入門 ● 主体 ○ AWSで何らかの操作を行う主体 ○ スコープに合わせて微妙に違う用語が使われる ○ Principal ■ AWS リソースに対する Actions / Opeartions をリクエストできる ユーザーまたはシステムのこと ○ Entity ■ IAMのリソースのうち認証に使われるもの ○ Identity ■ 認可されうるIAMリソース ○ 細かい違いはあれど「AWSへのアクセス時の主語となるもの」くらいに 思っておいてそこまで困ることはない ● ARN ○ Amazon Resource Name の略でAWSリソースを一意に識別する文字列 ○ IAMにおいて、アクセス対象などを指定する時には全てARNを用いる ○ arn:partition:service:region:account-id:resource-id という形式 ○ 具体例 ■ IAM User arn:aws:iam::123456789012:user/johndoe IAM の用語

© 2015 - 2024 Nowcast Inc. 21 3. AWS IAM 徹底入門 ● IAM のリソース（後述） ○ Root user ○ IAM User ○ IAM Group ○ IAM Role ○ IAM Policy ● Request 関係（後述） ○ Request ○ Actions / Operations ○ Principal ○ Environment data ○ Resource data ● AWSアカウント ○ AWSのリソースのコンテナのことで、テナントと言い換えても良い ○ 一般的にアカウントというとユーザーアカウントの意味が多く IAM User が対応するが AWSアカウントというと全く別物なので「アカウント」という単語の使い方には要注意 IAM の用語

© 2015 - 2024 Nowcast Inc. 22 3. AWS IAM 徹底入門 ● Principal (IAM User / Role) に IAM Policy を適切に 付与することで事前に権限を与えておく ● Principal がリクエストを投げる ● AWSはリクエストを行ったPrincipalを認証する ● AWSはリクエストコンテキストの情報を元に、 リクエストに適用するポリシーを決定する ● Policy Evaluation Logic に従ってポリシーを評価し、 リクエストを許可するか拒否するかを決定する ● 許可されればPrincipalはリソースにアクセスできる IAMにおける認証認可の流れ

© 2015 - 2024 Nowcast Inc. 23 3. AWS IAM 徹底入門 AWSへのアクセス時の主語となるもの ● IAM User ○ AWSを利用するユーザーやアプリケーションを表すエンティティ ○ user名と認証情報（コンソールパスワード・アクセスキー）で構成される ■ 認証を強固にするためにMFAを設定することができる（推奨） ■ IAM User の認証情報は長期的なもの ● IAM Role ○ AWSアカウントで作成できる特定のアクセス権限を持ったIAM Identityのこと。 ○ 認証の基礎となるAWSリソースという意味ではIAM userと似ているが、以下のいくつかの点で異なる。 ■ IAM Userは基本的に1人の特定の人が利用することを想定しているが、 IAM roleは必要とする任意の人が利用できるように設定できる ■ IAM Userは長期的な認証情報（パスワードやアクセスキー）で認証を行うが、 IAM Roleは一時的な認証情報で認証を行う ● IAM Group ○ IAM User をグループ化したもので、Userへのポリシーのアタッチを容易にするための機能 ● Root User ○ AWSアカウントをはじめて作成した時にされるユーザーのこと ○ Root User は最も強い権限を持っているためなんでもできてしまう ○ そのためMFAの設定だけして普段は基本的に使わないことが推奨されている IAM User / Role / Group and Root User

© 2015 - 2024 Nowcast Inc. 24 3. AWS IAM 徹底入門 ● IAM User や AWS サービスが Assume Role で特定の IAM Role を引き受けたセッションを作成することで、 ユーザーやシステムがAWSのリソースを（Roleが持つ権限の範囲で）利用できるようになる ● "assume role" は「roleを引き受ける」みたいなニュアンス ○ 特定の役割をもった帽子を被り、 その役割の権限は適宜使えるようになるみたいなイメージ ● Assume Role を実行すると以下の３つからなる一時的な認証情報が 返却され、これを利用することで一定期間認証ができるようになる。 ○ Access Key ○ Secret Access Key ○ Session Token ● Assume Role を実行できる人は、実質 IAM Role の権限を使える人 ということになるので適切に制限する必要がある ○ IAM Role の Resource based policy である 信頼ポリシーに「誰がAssume Roleをできるか」を 記載することで制限する Assume Role AWS再入門ブログリレー2022 AWS IAM編 より

© 2015 - 2024 Nowcast Inc. 25 3. AWS IAM 徹底入門 認証情報には長期的なものと、一時的なものがある ● IAM User : 長期的な認証情報 ○ その名の通り有効期限が数ヶ月などと長いものから、場合によっては有効期限がないような認証情報 ○ ユーザーが保存し適宜利用することになるため、管理が大変 ○ 具体例：IAM User のコンソールパスワード ● IAM Role : 一時的な認証情報 ○ その名の通り有効期限が非常に短く、数分から数時間で失効するような認証情報 ○ 一時的な認証情報はユーザー側で保存されることはなく、ユーザーのリクエストに応じて動的に生成する ○ 一度作った一時的な認証情報が失効してしまったら再度新しい一時的な認証情報を作ってもらう ■ 失効したものが再利用されることはない ○ 具体例：IAM Role が利用する一時的な認証情報 IAM Role が使える場合にはなるべく IAM Role を使っておくのが良い User vs. Role 〜長期的認証情報と短期的認証情報〜

© 2015 - 2024 Nowcast Inc. 26 3. AWS IAM 徹底入門 ● Request ○ Principal が AWS のリソースへアクセスしようとした時に、APIやCLIを通じてAWSにリクエストを投げることになる ○ リクエストには「誰が(Who)」「何に対して(What)」「どんな操作を(How)」「いつ・どこから（When/Where）」実行しよ うとしているかという情報が含まれる ■ Who → Principals ● IAM User / IAM Role / Root User ■ What → Resources ■ How → Actions / Operations ● リソースのCRUDなどがサービスごとに定義されている ● 具体例： s3:GetObject や s3:PutObject など ● Action と API は基本的には１対１対応しており、 API Reference を見ることでどのようなActionがあるか分かる ■ When/Where → 環境データ ● IPアドレス、ユーザーエージェント、時刻など ○ AWSはこの情報をリクエストコンテキストにし、リクエストの評価と認可に利用する AWSにおけるリクエスト

© 2015 - 2024 Nowcast Inc. 27 3. AWS IAM 徹底入門 IAM Policy はAWSの認可を司るリソースで JSON ドキュメントとして表現される。 AWSではポリシーを Identity や Resource に関連づけることでアクセス許可を定義する（認可の設定をする）。 IAM Policy にもいくつか種類がある。 ● Identity based policy ○ Identity (User/Group/Role) に対して付与する Policy ○ 対象のIdentityが「何に対して何をできるか」を規定する ● Resource based policy ○ S3バケットなどAWSの様々なリソースに対して付与するPolicy ○ 対象のリソースは「誰がどのように利用して良いのか」を規定する ● Organization SCPs：難しいので後述 ● Access Boundary / ACL / Session Policy : 今回は割愛 IAM Policy

© 2015 - 2024 Nowcast Inc. 28 3. AWS IAM 徹底入門 IAM Policy はAWSの認可を司るリソースで JSON ドキュメントとして表現される。 AWSではポリシーを Identity や Resource に関連づけることでアクセス許可を定義する（認可の設定をする） IAM Policy にもいくつか種類がある ● Identity based policy ○ Identity (User/Group/Role) に対して付与する Policy ○ 対象のIdentityが「何に対して何をできるか」を規定する ○ 主語は対象のIdentityなのでPrincipalsはいらない ○ 付与できるポリシーの種類が３つある ■ AWS Managed Policy ● AWSが作成・管理しているポリシー ● 例：AmazonS3FullAccess はS3に関する任意のActionを許可するポリシー ■ Customer Managed Policy ● 顧客が自由に作成・管理するポリシー ● 最小権限の原則を実現するためには利用が必要 ■ Inline Policy ● UserやRoleに直接埋め込まれたポリシー ● 他のIdentityに転用などはできないが、IdentityとPolicyが1対1に対応するような場合に便利 IAM Policy - Identity based policy

© 2015 - 2024 Nowcast Inc. 29 3. AWS IAM 徹底入門 IAM Policy はAWSの認可を司るリソースで JSON ドキュメントとして表現される。 AWSではポリシーを Identity や Resource に関連づけることでアクセス許可を定義する（認可の設定をする） IAM Policy にもいくつか種類がある ● Resource based policy ○ AWSの様々なリソースに対して付与するPolicy ○ 対象のリソースは「誰がどのように利用して良いのか」を規定する ○ リソースに埋め込まれた inline policy となる ○ 具体例 ■ IAM roleの信頼ポリシー：誰がRoleを利用して良いか定義する ■ S3バケットのバケットポリシー：誰がS3バケットを利用して良いか定義する ○ 後述する通り、クロスアカウントアクセスを実現する際に非常に重要となる IAM Policy - Resource based policy

© 2015 - 2024 Nowcast Inc. 30 3. AWS IAM 徹底入門 IAM Policy はAWSの認可を司るリソースで JSON ドキュメントとして 表現される。Identity based policy の主要な構成要素は以下。 ● Effect ○ Allow or Deny ● Action (How) ○ s3:GetObject など許可をするActionを指定する ○ API Reference を見るとActionがリストアップされていて便利 ● Resource (What) ○ Actionの対象となるリソースをARNで指定する ● Condition (When / Where) ○ ポリシーを評価する条件を指定する ○ 特に条件がなければ書かなくて良い ○ 具体例 ■ 特定のIPアドレスかどうか ■ MFAが有効化されているかどうか Identity based policy の JSON の構造 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:List*", "s3:Get*" ], "Resource": [ "arn:aws:s3:::confidential-data", "arn:aws:s3:::confidential-data/*" ], "Condition": {"Bool": { "aws:MultiFactorAuthPresent": "true" }} } ] } Identity based policy の例

© 2015 - 2024 Nowcast Inc. 31 3. AWS IAM 徹底入門 IAM Policy はAWSの認可を司るリソースで JSON ドキュメントとして 表現される。Resource based policy の主要な構成要素は以下。 ● Effect ○ Allow or Deny ● Action (How) ○ s3:GetObject など許可をするActionを指定する ○ API Reference を見るとActionがリストアップされていて便利 ● Resource (What) ○ Actionの対象となるリソースをARNで指定する ● Principal (Who) ○ Resource based policy の場合に指定する ○ 「誰が」Actionを実行するのかを指定する ● Condition (When / Where) ○ ポリシーを評価する条件を指定する ○ 具体例 ■ 特定のIPアドレスかどうか ■ MFAが有効化されているかどうか Resource based policy の JSON の構造 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/johndoe" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::carlossalazar/*", "arn:aws:s3:::carlossalazar" ] } ] } Resource based policy の例

© 2015 - 2024 Nowcast Inc. 32 3. AWS IAM 徹底入門 以下のようなステップで様々なポリシーが評価されていく ● 暗黙的Denyからスタート ● 明示的Denyされるものがあれば まず拒否をする ● Organization SCPs があれば まずそれを評価 ● 対象リソースに Resource based policy が あればそれを評価 ● 対象プリンシパルに Identity based policy が あればそれを評価 ● … ● 途中でDenyされず最後まで 行けばようやくAllow！ ポリシー評価論理

© 2015 - 2024 Nowcast Inc. 33 3. AWS IAM 徹底入門 Account A のユーザー UserA が Account B のS3バケットにアクセスするというような クロスアカウントなアクセスを許可するためには以下の２つ両方のポリシー設定が必要。 ● リクエスト元 ○ Account A のあるユーザーに Identity based policy で 対象S3バケットに対するActionを許可していること ● リクエスト ○ Account B にあるS3バケットのバケットポリシー (Resource based policy) で Account A のユーザー UserA からのActionを許可していること これらの両方の設定がされていて初めてAWSはリクエストを許可する。 片方だけの設定だと拒否されてしまうので注意が必要。 クロスアカウントアクセスの際のIAM設定

© 2015 - 2024 Nowcast Inc. 34 4. 開発時のTips

© 2015 - 2024 Nowcast Inc. 35 4. 開発時のTips ドキュメントにも種類がある ● User Guide ○ AWSのサービスの解説をしたドキュメント ○ AWSの実際のサービスに沿った形で IAMの設定方法などについても記載がある ● API Reference ○ そもそもどんな Actions / Operations が 存在するのか一覧になっている ● Service Authorization Reference ○ IAM Policy の Resource や Condition あたりで困った時には これを見ると良い AWSのドキュメントに慣れよう

© 2015 - 2024 Nowcast Inc. 36 4. 開発時のTips ドキュメントにも種類がある ● User Guide ○ AWSのサービスの解説をしたドキュメント ○ AWSの実際のサービスに沿った形で IAMの設定方法などについても記載がある ● API Reference ○ そもそもどんな Actions / Operations が 存在するのか一覧になっている ● Service Authorization Reference ○ IAM Policy の Resource や Condition あたりで困った時には これを見ると良い AWSのドキュメントに慣れよう

© 2015 - 2024 Nowcast Inc. 37 4. 開発時のTips ドキュメントにも種類がある ● User Guide ○ AWSのサービスの解説をしたドキュメント ○ AWSの実際のサービスに沿った形で IAMの設定方法などについても記載がある ● API Reference ○ そもそもどんな Actions / Operations が 存在するのか一覧になっている ● Service Authorization Reference ○ IAM Policy の Resource や Condition あたりで困った時には これを見ると良い AWSのドキュメントに慣れよう

© 2015 - 2024 Nowcast Inc. 38 4. 開発時のTips ● aws sts get-caller-identity ○ 現在使っているAWSアカウントやユーザー・ロールの情報が確認できる ○ IAMのエラーが出たら真っ に確認するのがおすすめ ○ $ aws sts get-caller-identity { "UserId": "AIDASAMPLEUSERID", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/DevAdmin" } 便利コマンド

© 2015 - 2024 Nowcast Inc. 39 4. 開発時のTips ● aws configure list ○ 現在何経由で認証の設定がされているかを確認できる ○ 認証設定の優 順位は後述 ○ $ aws configure list Name Value Type Location ---- ----- ---- -------- profile None None access_key ****************ABCD config_file ~/.aws/config secret_key ****************ABCD config_file ~/.aws/config region us-west-2 env AWS_DEFAULT_REGION 便利コマンド

© 2015 - 2024 Nowcast Inc. 40 4. 開発時のTips ● 主要な認証情報は以下の順番に確認される 1. command line options a. --region / --output / --profile など 2. 環境変数 a. AWS_PROFILE / AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS など 3. CLI credentials a. Mac では ~/.aws/credentials 4. CLI configs a. Mac では ~/.aws/config 5. Container credentials 6. Amazon EC2 Instance Profile credentials ● https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-precedence より aws cli の認証情報設定と優先順位

© 2015 - 2024 Nowcast Inc. 41 Appendix

© 2015 - 2024 Nowcast Inc. 42 Appendix IAM リソースの arn は以下の形式のどれか ● arn:aws:iam::account:root ● arn:aws:iam::account:user/user-name-with-path ● arn:aws:iam::account:group/group-name-with-path ● arn:aws:iam::account:role/role-name-with-path ● arn:aws:iam::account:policy/policy-name-with-path ● arn:aws:iam::account:instance-profile/instance-profile-name-with-path ● arn:aws:sts::account:federated-user/user-name ● arn:aws:sts::account:assumed-role/role-name/role-session-name ● arn:aws:iam::account:mfa/virtual-device-name-with-path ● arn:aws:iam::account:u2f/u2f-token-id ● arn:aws:iam::account:server-certificate/certificate-name-with-path ● arn:aws:iam::account:saml-provider/provider-name ● arn:aws:iam::account:oidc-provider/provider-name https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids より IAM リソースの arn

© 2015 - 2024 Nowcast Inc. 43 Appendix IAMでは User / Role / Policy などを作成する時に必ず一意のID（例：AIDAJQABLZS4A3QDU576Q ）を割り当てる。 普段はユーザーフレンドリーなARN形式を利用するのであまり見ないが、ログなどにはこのIDが現れたりする。 このprefixはリソースの種類ごとに以下のように決まっている。 ● AIDA : IAM User ● AROA : IAM Role ● AKIA : Access Key ● ASIA : Temporary access key ID ● … https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids より IAM ID

© 2015 - 2024 Nowcast Inc. 44 Appendix CloudTrail を利用すると、様々なAPI(Action)のリクエストに 対応するログが保存される。 IAM の GetUserPolicy の例はこちら。 IAM Policy の Condition で評価されるような要素が 多数並んでいることがわかる。 CloudTrail ログの例 { "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::444455556666:user/JaneDoe", "accountId": "444455556666", "accessKeyId": "AKIAI44QH8DHBEXAMPLE", "userName": "JaneDoe", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2014-07-15T21:39:40Z" } }, "invokedBy": "signin.amazonaws.com" }, "eventTime": "2014-07-15T21:40:14Z", "eventSource": "iam.amazonaws.com", "eventName": "GetUserPolicy", "awsRegion": "us-east-2", "sourceIPAddress": "signin.amazonaws.com", "userAgent": "signin.amazonaws.com", "requestParameters": { "userName": "JaneDoe", "policyName": "ReadOnlyAccess-JaneDoe-201407151307" }, "responseElements": null, … }

© 2015 - 2024 Nowcast Inc. 45 Appendix ● 『図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』　 成 滋生 ● 『AWSの薄い本　IAMのマニアックな話』　佐々木拓郎 ● 『イラスト図解式 この一冊で全部わかるセキュリティの基本』　みやもと くにお , 大久保 隆夫 References

© 2015 - 2024 Nowcast Inc. 46 Appendix 毎年サマーインターン(有償)を実施しています！ぜひご参加ください！ 2024年の実施概要は以下のとおりです。 実施期間　：　2024年8月26日(月)〜2024年8月30日(金) 要項ページ： https://hd.finatext.com/news/20240529/ 【ソフトウェアエンジニア】： - Go言語とAWSを使ってシステムの開発や AWSの技術選定をやってもらいます - AWSの方がゲストで来ます 【データサイエンティスト】： - Python/SQLで実践的ビッグデータ分析！ - 普段触れない、POSやクレカのデータを 利用して実際の分析業務を体験できます Finatext HD のサマーインターン 実施概要 ↓ 申し込み ↓フォーム

© 2015 - 2024 Nowcast Inc. 47 Appendix 公式Xやテックブログもぜひご覧ください！ Finatext HD の各種リンク 公式X→ テックブログ→

© 2015 - 2024 Nowcast Inc. 48