IAM Best Practices from Amazon Web Services AWSのPrincipal Security Solutions ArchitectであるMax Ramsayが、AWS IAMのベストプラクティスを説くスライドの紹介。AWS IAMとは、AWSのサービスやリソースへのアクセスをセキュアに制御するためのサービス。 クラウド･ベンダーはメインとなる仮想サーバー機能やストレージ機能だけではなくて、IAMのような地味ながら極めて重要な機能を提供できることが大切であると個人的には感じている。ところが、IAMがあっても十分に活用されていない場合もあるので、この良スライドを意訳しつつ日本語でサマリーを書いてみる。 最小権限の原則といったセキュリティ管理における常識的な内容を、AWS IAMという機能にマッピングするのが本プレゼンテーションの趣旨なので、実現方法の説
GCP の IAM をおさらいしよう
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 6日目の記事です。 TL;DR本記事ではGoogle Cloud Platform (GCP) での ユーザーや権限を管理する IAM について整理していきます。 はじめにクラウドを使う上で、ユーザー管理や権限管理は重要ですよね。GCP を使う際に、どのようにユーザー管理できるのか、権限管理や認証を整理してみようと思います。GCP では権限管理を Identity and Access Management（ IAM ）というもので管理しています。IAMでは、誰が、どのような操作を、何に対して行えるかというものを定義・管理します。これによりアカウントの追加・削除や権限付与がシンプルになり、管理が容易になります。 IAMのユーザーと権限GCP で利用できるアカウ
「セキュアで堅牢なAWSアカウント」を実現する CloudFormationテンプレート - ①サービスの有効化 - Qiita
はじめに AWSにはアカウントやリソースへの脅威検知に対応した、AWS IAM Access Analyzer, AWS Security Hub, Amazon Detective, Amazon Inspector, Amazon GuardDuty, AWS CloudTrail, AWS Config などのサービスが用意されています。 また、AWS Security Hub では、CIS AWS Foundations Standard , Payment Card Industry Data Security Standard , AWS Foundational Security Best Practices Standard などのセキュリティ標準が公開されており、このガイドラインは、AWSアカウントをセキュアに保つために必要なAWSのセキュリティ設定を集めたベストプラクテ
こんにちは、臼田です。 みなさん、セキュリティ活動してますか？(挨拶 今回はAWS公式トレーニングのSecurity Engineering on AWSで利用できる参考リンクをまとめました。 参考リンク集 モジュール00: コースの紹介 AWS Security Fundamentals (Second Edition) (Japanese) 事前に受けておくといい無料のEラーニング Getting Started with AWS Security, Identity, and Compliance (Japanese) (日本語吹き替え版) IAM周辺の無料のEラーニング モジュール01: AWSのセキュリティ AWS クラウドにおける NIST サイバーセキュリティフレームワークへの準拠 – 日本語のホワイトペーパーを公開しました AWSセキュリティ対策を考える上で参考になるフレー
はじめに こんにちは。望月です。 過去に本ブログで、IAM Roleの仕組みについて都元から解説がありました。 - IAMロール徹底理解 〜 AssumeRoleの正体 IAM Roleの仕組みについて非常にわかりやすく解説されていますので、ぜひ読んでみてください。今日はもう少し利用側の観点に立ったブログを書いてみようと思います。 IAM Roleってどうやって使われてるの IAM Roleを利用する目的は、「ソースコード内にAWSのAPIキーをハードコードすることなく、AWSのAPIを叩きたい」というものが殆どだと思います。ですが、なぜIAM Roleを利用すると、アクセスキーをソースコードで指定することなくAWSのAPIが利用可能になるのでしょうか。 今日はその仕組みについて知りたくなったので、AWS SDK for Rubyのソースコードから読み解いてみました。SDKのバージョンは1
それぞれのフェーズの詳細は以下のようになります。 当該アクセスキーを利用した不正な操作が行われる 流出したアクセスキーを利用し以下の操作が行われました。APIレベルの操作です。一連の操作はスクリプト化されているように見受けられます。 CreateAccessKey 流出したアクセスキーを利用し新規のアクセスキーを作成 DeleteAccessKey 流出したアクセスキーを削除 CreateUser IAMユーザーを作成（権限不足により失敗） CreateKeyPair 新規のアクセスキーを利用しキーペアを作成 RunInstances 全リージョンでインスタンスを起動 各リージョンで20のインスタンスが立ちあがる（起動上限はデフォルトのまま） m5.24xlargeなどインスタンスサイズが大きいものが優先される その後、起動したインスタンスにて仮想通貨Moneroのマイニングが行われました
（2019/04 追記 この記事の情報は古いです。今では、GCPのIAMでも IAM Custom Roles によってカスタマイズしたロールが作れたり、Cloud IAM Conditions が登場してリソースの制限がしやすくなったりしています。また、メディア管轄のAWS Organizationsの活用については 「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018 もご覧ください） メディア事業（アメーバなど）を中心にAWS/GCPを担当している柿島大貴です。前回は、Google Cloud Platform（GCP）の各プロジェクトでコストを追える環境を作る を書きました。前回の続報としては、一部には使ってもらいつつも、可視化の部分で cloudyn を検証中です。 今回は、GCPのリソースの認可の話になります。GCPの利
テクニカルトレーナーと学ぶ AWS IAM ロール ~ ここが知りたかった ! つまずきやすい部分を理解してモヤっとを解消 - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「あかねさす柘榴の都」と「クジマ歌えば家ほろろ」です。 今回は IAM ロールの説明を、私なりに感じた「理解する時につまずきやすい部分」を紹介する形式でお伝えします ! これは自身の経験やトレーニングの受講者からよくいただく相談などを踏まえたものなので、今まで IAM ロールの説明を聞いたり読んだりしてきたけどいまいちピンときていない方に、ぜひモヤッとを解消していただきたいです ( ･∀･)=b というのも、私は業務でお客様に AWS の様々なトレーニング を提供しているのですが、AWS Identity and Access Management (IAM) について説明をした後に「トレーニングを受講したことで、今まで難しいと感じていた IAM ロールを理解できた !」と言っていただくことがあります。そのた
[2021年版]Amazon GuardDutyによるAWSセキュリティ運用を考える | DevelopersIO
Amazon GuardDutyは脅威検知のサービスです。うまく活用してインシデントに対応するために運用方法をまとめます。 こんにちは、臼田です。 みなさん、AWSのセキュリティ運用してますか？(挨拶 Amazon GuardDutyはAWS上の脅威検知サービスです。今回はこのサービスにフォーカスしたセキュリティ運用を考えてみます。 ちなみにAWS Security Hubについても同じようにセキュリティ運用についてまとめたので以下もご確認ください。 AWSセキュリティ全体像 フォーカスしていく前に全体の整理をします。以下にざっくりとAWSにおけるセキュリティの要素について書き出してみます。 AWSレイヤー IAM管理 ネットワークセキュリティ 設定管理 OS/アプリレイヤー 不正プログラム対策 脆弱性管理 セキュアアプリケーション アプリケーション保護 全体管理 ガバナンス・コンプライア
![[2021年版]Amazon GuardDutyによるAWSセキュリティ運用を考える | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/667f87d2f54fdeff2f01ae7c6408e45a44404f8e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-guard-duty.png)
GitHub Actionsに「強い」AWSの権限を渡したい ~作戦3 - AssumeRole with Google ID Token ~ - KAYAC engineers' blog
こんにちは。技術部の池田です。 この記事では、Github Actions上に「強い」AWSの権限を渡すために以下のことを行います。 App Runnerでお手軽にGoogle ID Token 取得するためのWeb Applicationを動かす。 Web Applicationから取得できるGoogle ID Tokenを信頼するIAM RoleにAssumeRoleする。 AssumeRoleによって得られた一時的な強い権限で、強い権限を要求する作業(Deploy, Terraform Apply)をGithub Actionsで行う。 これにより、Github Actions上にAWSのアクセスキーを置かずに、ある程度安全な方法でAWS上での強い権限を要求する操作を実行できます。 そのため、例えばGithub Repositoryに不正アクセスされてしまったとしても、AWSの本番環
AWS IAMどうしましょ
AWS IAMの以下のリソースについてどのように考えればいいか - Identity-based Policy vs Resource-based Policy - Permission Boundary - Tag-Based Policy - AWS SSO vs Federated IAM Role
よく訓練されたアップル信者、都元です。ブログのエントリみてればわかるとおもいますが、最近AWSのセキュリティに凝ってます。 AWSにおける権限管理について知識を深め、各所に適切な設定を行って行くのは大事なことです。これが基本です。しかし、自分が管理するAWSの各種リソースについて、何らかの意図しない変更があったことにすぐ気付ける体制は整っていますでしょうか？ 仮に、アクセスキーが悪意のある第三者に漏洩し、当人がその事実に気づいていないケースを考えます。悪意の第三者は、きたる攻撃のタイミングに備え、各所にバックドアを仕込もうとするでしょう。 こっそりとIAMユーザを増やしているかもしれません。 アクセスキーが1ユーザにつき2つ作れることをいいことに、自分用のキーを追加で作成しているかもしれません。 IAMロールに対するIAMポリシーを書き換えているかもしれません。 セキュリティグループにおけ
クラウドの運用者に焦点を当てた、技術者向けの新しいテックイベント「Cloud Operator Days Tokyo 」。ここで株式会社カサレアルの新津氏が「これやったの誰？」をテーマに登壇。自動化したオペレーションに対して生じた疑問と学びについて紹介します。 自己紹介と今回のテーマ 新津佐内氏（以下、新津）：みなさん、こんにちは。株式会社カサレアルの新津佐内と言います。本日は「これやったの誰？」というタイトルのお話をします。 「これやったの誰？」についてですが、DevOpsと合わせて自動化を進めていく中で、自動化したオペレーションに対しても生じたこの疑問に、実業務の中であらためて向き合ってみました。上記事例の詳細と現時点での我々の答えを紹介します。 まず本日お話しする内容ですが、スライドに書かれているような基盤の運用担当者のユースケースに関わるお話になります。どのようなユースケースかとい
【SAP試験対策】IAMの勉強であやふやな理解だったポイントをしっかり整理する | DevelopersIO
AWS認定のSolution Architect Professional試験用に、AWS IAMに関連したキーポイントを断片的にまとめました。 「SAPの試験問題って、大学センター試験の国語に似てね？」 UdemyにあるAWS認定のSAP模擬試験を4本こなした結果、問題の傾向として気づいたことです。どう考えても絞りきれない選択肢が2つ3つあるんですよね〜。 私は受験教科の中で国語が一番苦手でだったので、塾の先生から「問題文に書いてあることに沿って、合っているものではなく、間違ってないものを選べ」と、しょっちゅう教えられていたことを思い出しました。SAPの試験でも同じように「問題の要件と関係ない用語が含まれている選択肢をまず消去し、選択肢が2つ残ってしまったら、問題文に書いてあることに沿った、間違っていない選択肢を選ぶ」ことが大事だなと感じています。 さて、「間違っていないかどうか」を判断
森永です。 今回は技術寄りの話ではなく、概念的な話です。 がっつりインフラエンジニアの方というよりは、情シスなどでAWSに関わるの非エンジニアの方向けに書いていきます。 AWSを利用する上ででてくる「アカウント」についてまとめてみました。 オンプレと何が違うの？、というお話をよく耳にしますので、オンプレとの対比を挟みながら説明していきます。 AWSで使用するアカウント AWSでは以下の3つのアカウントに大別されます。 OS（Linux/Windows）アカウント IAM AWSアカウント この中でさらに2つに大別でき、OSアカウントはOS以上のレイヤについて、IAMとAWSアカウントは物理やネットワークレイヤといったAWSで管理されるレイヤについて管理するアカウントになっています。 各アカウントについて、管理方針も含めてもう少し深くまとめていきます。 OSアカウント 特に説明はいらないかと
TerraformでAWSアカウントを作るのは簡単だけど削除はひと手間かかったのは昔の話 | DevelopersIO
以前「TerraformでAWSアカウントを作るのは簡単だけど削除はひと手間かかる」というブログを書きました。 タイトル通り、TerraformでAWS Organizations配下のアカウントを作成するのはaws_organizations_accountリソースを定義してterraform applyするだけなのでチョー簡単ですが、削除はaws_organizations_accountリソースを削除してterraform applyするだけではだめで、色々設定が必要になって大変だという内容です。 ですが、少し前に激アツアップデートがありました。 そしてこの簡単削除機能がTerraformでも利用可能になっていることを知ったのでレポートします。 close_on_deletion flag Terraform AWS Provider v4.9.0でaws_organizations
はじめに こんにちは、川原です。 AWSのIAMサービスでは、各AWSサービスへの操作をアクセス制御するために「ポリシー」という概念があります。 AWSのドキュメントを読んでいると、ポリシーにはいくつか種類があることに気付くかと思います。本ブログではそれらのポリシーについて整理してみたいと思います。 ポリシーの基本 ポリシーは基本的に、「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述します。 記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現しています。 例えば、以下のJSONはAWS側で用意しているAmazonS3ReadOnlyAccessという名前のポリシーです(後述するユーザーベースポリシーのAWS管理ポリシーに該当)。
大栗です。 先程既存のEC2に対してIAM Roleを設定することができるようになりました！早速試してみます。 New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI Attach an IAM role to your existing Amazon EC2 instance 2017年3月6日現在 Management ConsoleでもIAM Roleの設定が可能になっています。 [アップデート] EC2コンソールで既存のEC2インスタンスに対してIAM Roleをアタッチ、変更ができるようになりました IAM Roleとは？ IAM Roleとは、AWSのサービスに対してアクセス権限を付与する機能です。IAM Roleでは対象サービスのみにアクセス権限を設定できアクセスキ
![[アップデート]既存のEC2にIAM Roleを付与できるようになりました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/58278067871ebaae68a873315f4dd4b9b78f6b5a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_EC2.png)
本投稿は DPE Camp blog series の一部です。 こんにちは。 Platform Infra の Kenichi Sasaki (@siroken3) です。メルカリでは主にAWSの管理を業務にしています。今回の投稿ではAWS構成管理リポジトリのセキュアなCI/CD環境を構築した件について紹介します。 背景 メルカリにおけるAWSの役割 メルカリにおけるAWSの利用の歴史は古く、商品画像を格納するためのストレージとしてS3をサービス開始当初から採用しています。その他S3はMySQLデータベースのバックアップ先、パートナー各社様とのデータ連携のための AWS Transfer Family のバックエンドとして使用しています。また2014年当時のUSメルカリのサービス開始時のメインインフラはAWS上にありました。 直近ではお客さま電話窓口やサポート担当の稼働管理ツールとして
大阪オフィスのYui(@MayForBlue)です。 複数のアカウントで作業している際にアカウントの切り替えを楽にしてくれるIAMのスイッチロールですが、どんな仕組みになっているのかよくわからずモヤモヤしていたので、実際に手を動かして理解してみました。 目次 スイッチロールとは 実装の手順 まとめ 最後に 参考記事 スイッチロールとは 複数のアカウントで作業する際にアカウントの切り替えを楽にする機能 IAMについてはこちらの記事がわかりやすいです。 AWS初心者にIAM Policy/User/Roleについてざっくり説明する 実装の手順 複数アカウント間でスイッチロールするために必要な手順を実際にやってみます。 スイッチ先での作業 IAMの画面でロールを選択し、「ロールの作成」をクリックします。 信頼する対象に「別のAWSアカウント」を選択し、スイッチ元のAWSアカウントIDを入力して次
タイトル修正しました。最初「TerraformでIAM Policyを書く方法4つと失敗する方法ひとつ」というものでしたが、失敗する方法は単に私の書き方が間違ってただけでした TerraformでIAM Policyを書く方法は色々とあるので、紹介していきます。 今回は例として、こちらの公式ドキュメントに出てくる以下ポリシーを使いたいと思います。 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } } ファイル外だし policyの中身はtfファイルに書かず、JSONファイルとして外だしします。それをfile関数を使って参照します。 fil
忘れないようにメモ。 発表時と違う点は エンジニアの総数修正 IAMがダブってた PRのReviewerについて格助詞の使い方を間違えていたのを修正。 -> 「を」と「の」
GCP上では誰もが同じ権限に、そして開発者全員が一時的に権限付与できるツール「granter」について | Money Forward Kessai TECH BLOG
GCP上では誰もが同じ権限に、そして開発者全員が一時的に権限付与できるツール「granter」について こんにちは、マネーフォワードケッサイ（以下MFK）SREチームのshinofaraです。今回は権限の仕組みを見直した話と、それを実現する為に開発したgranterというツールについてお話したいと思います。 また今回granterのcore部分をmfkessai/granter_coreとして公開しています。 granter登場以前の世界 MFKでは、2017年の創業時からGoogle Cloud Platform(以下GCP)とGoogle Workspace（当時はG Suite）を選択して利用してきました。 GCPの Cloud Identity and Access Management (IAM)では、Workspaceで作成した個人のアカウントだけでなく、Groupに対して権限
はじめに こんにちは、虎塚です。 組織でAWSアカウントを利用する際には、担当者ごとにIAMユーザを払い出し、各ユーザが自分でMFA (Multi-Factor Authentication) を有効にすることが推奨されています。クラスメソッドでも、お客様の環境ごとにIAMユーザを作成し、MFAを設定していただくようにお願いしています。 ここで問題になるのが、IAMのポリシーです。IAMユーザ本人に自分自身のMFAを管理できるようにするには、どんなポリシーが適切なのでしょうか？ このテーマは、当ブログの過去記事でも何度か登場していますね。 一般のIAMユーザにMFAを設定してもらう方法 ｜ Developers.IO IAMによるAWS権限管理 – プロジェクトメンバーへの権限付与方針に潜む闇 ｜ Developers.IO 2015年8月現在、上記で紹介されたポリシーでは正常に動かなかっ
2021/8/17 に行われた AKIBA.AWS ONLINE #06 – AWS IAM 編 で 『ここが嬉しいABAC、ここが辛いよABAC』 というタイトルで登壇しました。 登壇資料を共有します。参考になれば幸いです。 資料 参考リンク 属性ベースのアクセス制御（ABAC）とは？ メリットと適切なアクセス制御モデル | Okta AWS の ABAC とは - AWS Identity and Access Management IAM チュートリアル: タグに基づいて AWS リソースにアクセスするためのアクセス許可を定義する - AWS Identity and Access Management IAM でのポリシーとアクセス許可 - AWS Identity and Access Management SaaSテナント分離をAWS IAMとABACで実装する方法 | Ama
Terraformとdriftctlで行うGoogle Cloud 権限管理の省力化 - ZOZO TECH BLOG
はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは日々複数のGoogle Cloudプロジェクトを管理しています。これらのプロジェクトでは、データサイエンティストやプロジェクトマネージャーなど別チームのメンバーが作業することもあり、必要に応じてメンバーのGoogleアカウントへ権限を付与しています。 権限の付与はプロジェクトの管理者であるMLOpsブロックメンバーが行いますが、これは頻繁に発生する作業でありトイルとなっていました。 また権限付与後はこれらを継続的に管理し、定期的に棚卸しすることで不要になった権限を削除する必要があります。しかし当初の運用だと権限の棚卸しの対応コストが大きく、これが実施されずに不要な権限が残り続けるという課題もありました。 本記事ではMLOpsブロックで抱えていたGoogle Cloudプロジェクト内での権限管理における
渡辺です。 最近は、システムの開発支援としてAWS環境構築などに関わる事が多いです。 そこで、開発者側視点で押さえておきたいAWSのノウハウや基礎知識を書いて展開してみたいと思います。 今回はEC2で動くプログラムがアクセスキー/シークレットキーを使わずにRoleを利用すべき、という話です。 Roleとは？ RoleはIAMの機能のひとつで、アクセスキー/シークレットキーを使わずに各種AWSリソースにアクセスすることができます。 例えば、EC2インスタンスからS3にオブジェクトを書き込んだり、SNSにメッセージを送信したりする場合に利用できます。 アクセスキー/シークレットキーとの違い ひとことで言えば、Roleはアクセスキー/シークレットキーに比べ、キーの管理をする必要がありません。 ただし、EC2インスタンスにしか割り当てることしかできません。 キー管理が不要 アクセスキー/シークレッ
え、IAM ユーザーを作らなくてもマネジメントコンソールにログインできるの!? – シングルサインオン考え方編 | Amazon Web Services
AWS Startup ブログ え、IAM ユーザーを作らなくてもマネジメントコンソールにログインできるの!? – シングルサインオン考え方編 みなさん、こんにちは。ソリューションアーキテクトの稲田（@inariku）です。 今回はセキュリティのお話です。近頃、ビジネスの成長にあわせて、セキュリティの重要性が増してきたスタートアップのお客様からよく「IAM ユーザーの管理の手間が増えてきた。IAM ユーザーの管理で抜け漏れが出そうで怖くなってきた。」などのお声を聞くことが増えてきました。 一般に、アカウント管理を効率化する観点で考えると、IAM ユーザーを作らないことが有効なプラクティスです。しかし、「IAM ユーザーを作らないとマネジメントコンソールに入れないんじゃ..」「AWS CLI が使えないんじゃ..」などと思われた方もいらっしゃると思います。では、どのようにすればよいのでしょう
望月@シアトルです。 今日はAmazon S3を複数名で利用するときの、IAM権限制御に関するTIPSのご紹介です。 想定する環境 S3は安価かつ高耐久性のストレージとして、AWS上でシステムが稼働しているかどうかに関わらず利用することが可能です。また、単純な保存領域としてだけでなく、S3 Static Website Hostingと呼ばれる機能を利用すれば、S3にHTMLなどの静的ファイルを配置しておくだけで簡単にWEBサイトを作れます。 この機能により、可用性・対障害性の高いWEBサーバを非常に安価(〜10円/月)でホスティングできます。 Static Website Hostingを利用する時には、S3にファイルを配置するだけで外部への公開ができますが、気にしなければならないことの一つに権限の管理があります。S3へのアップロード権限はAWS Identity and Access
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。 皆さんは定期的にIAMリソースの棚卸しや管理をしていますか？いつの間にか溜まっちゃってる不要なIAMユーザーやIAMポリシーは無いですか？ 不要なIAMリソースを放置することはセキュリティ的に危険です。不要なものは定期的に削除しちゃいましょう。 そこで今回は不要なIAMリソースを少しでも楽に棚卸しする方法をまとめてみました。下記ターゲットに当てはまる方は是非ご一読ください。 本記事のターゲット IAMリソースを管理していない方/出来ていない方 IAMリソースの棚卸しをマネジメントコンソール上から手動でポチポチやって時間がかかっている方 やりたいこと あまり時間をかけずにIAMリソースの棚卸しをしたい 普段使っていないIAMリソースや新規作成したIAMリソースを定期的に確認したい やってみた 今回は以下の3つの
Amazon Web Services ブログ AWS アカウントのセキュリティを改善するための 10 個の項目 クラウド・セキュリティを向上させたいと考えているなら、AWS のチーフ・インフォメーション・セキュリティ・オフィサー (CISO) であるステファン・シュミットが AWS re:Invent 2019で発表したクラウド・セキュリティのための上位 10 個の項目 を参照してみてはいかがでしょうか？ 下記が項目のサマリーです。皆様の理解のために、順番に説明していきます。 1) アカウント情報を正しく保つ AWS が AWS アカウントについて連絡が必要な場合、AWS マネジメントコンソールで設定された連絡先の情報を利用します。これは、アカウントを作成する時に指定した E メールアドレス、代替の連絡先の中で指定されている E メールアドレスになります。全ての E メールアドレスは個人
はじめに 2週間ほど前に、iPhone Xsが突然壊れ、いわゆるリンゴループに陥りました。Genius Barでもいろいろ調べてもらったのですが、水没でもなく、容量不足でもなく、ソフトウェアアップデートが起因でもなく、通電障害でもなく、原因はまったくもって不明です。Apple Careも切れていたので、交換修理の75,000円程度を払うのもバカバカしく、結局iPhone 12 Proに買い替えました。 ほとんどのデータをクラウドに逃がしているので、買い替え後の対応はスムーズで、初期設定～データ復旧までは数時間で完了することができました。みなさん、本当にバックアップは大事ですよ。 が、ひとつだけ問題がありました。二段階認証（ワンタイム認証）で使用する Google Authenticator です。 Google Authenticator のバックアップ Google Authentica
2023 年の BigQuery 権限管理
酒とゲームとインフラとGCP 第18回 発表資料
AWS IAM Userアクセスキーローテーションの自動化 | BLOG - DeNA Engineering
この記事は、 DeNA Advent Calendar 2021 の17日目の記事です。 こんにちは、 @karupanerura です。 普段はAWSやGCPを使って仕事をしています。 前作 に引き続き、AWS IAM Userのアクセスキーの定期的なローテーションを自動化したので、今回はそれについて書きます。 IAM Userの使いどころ IAM Userの利用にはアクセスキー（Access Key IDとAccess Key Secretの組）やコンソールログイン用のパスワードなどのクレデンシャルが必要です。 当然これらが漏洩すればそれを不正に利用され得るリスクがあるので、可能であればなるべくIAM Roleを利用するべきです。 IAM Roleならクレデンシャルの管理が不要で、アプリケーションやサービスに対してそのIAM Roleを通して任意の権限を与えることができるため、管理も非
最小権限のIAM Policy作成にCloudFormationのコマンドが役立つ | DevelopersIO
最小権限のIAM Policyを作成するのって地味に面倒ですよね。以前私は、Route53ホストゾーンにDNSレコード作成するのに必要な最小権限のPolicyを作るため、権限ゼロの状態から始めて、権限不足エラーが出るたびに権限を足していくという力技でPolicyを作ったことがあります。 Route53ホストゾーンにDNSレコードをTerraformで作成するのに必要な最小権限 | DevelopersIO もうちょっとスマートなやり方が、CloudFormation(CFn)のコマンドを使うとできる場合があることを学んだのでレポートします。 aws cloudformation describe-type そのコマンドが、 aws cloudformation describe-typeです。--typeオプションでRESOURCEを指定して、 --type-nameでCFnのリソースタイ
IAM の評価論理をやんわり押さえるセッション「やんわり押さえよう IAM の評価論理」で登壇しました #devio2021 | DevelopersIO
【やんわり】（副詞） ━ものやわらかであるさま。おだやかなさま。 （デジタル大辞泉より） コンバンハ、千葉（幸）です。 皆さんは IAM の評価論理って難しいと思っていませんか？ 実は…… … …… ……… その通り、難しいんです。 やれアインディティベースポリシーとリソースベースポリシーだの、アカウントをまたぐまたがないだの、ガードレールがどうだの、暗黙的だの明示的だの、覚えることがたくさんあって難しいです。 詳細な内容は必要に迫られたときに考えるとして、「だいたいこういうことでしょ」とやんわり理解する状態を本セッションでは目指していきます。 セッションの雰囲気 これが…… こうなる感じ雰囲気のセッションです。 セッションで学べること 章ごとにサマリを描きます。 1. IAM JSON ポリシー IAM のポリシータイプは 6 つあること IAM JSON ポリシーの構成要素として Ef
特定の IAM ロールのみアクセスできる S3 バケットを実装する際に検討したあれこれ | DevelopersIO
今回は S3 バケットへのアクセスを特定 IAM ロールからのみに限定して利用する機会がありましたので、設定方法と検討したあれこれをご紹介します。 やりたいこと 構成図はこんな感じ 前提条件 IAM ロールと S3 バケットは同一アカウントに存在する IAM ロールには S3 を管理する権限がアタッチされている 今回は AmazonS3FullAccess ポリシーをアタッチしています NotPrincipal でやってみる 「特定 IAM ロール以外は制限する」という考え方でパッと思いつくのは、以下のような NotPrincipal で制限する方法かと思います。 バケットポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "NotPrincipal": { "AWS": "arn:aws:iam::xxxx
Amazon Web Services ブログ 最小権限実現への4ステップアプローチ 前編 AWS のセキュリティベストプラクティスを実現するに当たり、「最小権限の原則」に戸惑ったことはありませんか？ AWS の利用では AWS Identity and Access Management （IAM）サービスを避けて通ることは出来ません。そのベストプラクティスとして掲げられているのが、最小権限の原則です。特に強固なセキュリティを求めるユースケースではこの原則の実現が課題になることが多いかと思います。本ブログでは、この最小権限の原則をシステマチックに検討するアプローチの一例をご紹介します。 はじめに 「最小権限を適切に運用する」ことを計画する際、まず思いつくのはシステムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与するというアプローチです。シンプルですが、権限が
amazon S3 のアクセス制御をIAMポリシーで行うメモ - teketeke_55の日記
IAMのポリシー作成機能を使用してS3をアクセス制御する S3だけフルアクセスできる { "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } ] } 機能を絞る場合 { "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "*" } ] } S3の特定のバケットのみフルアクセス(バケットとその中身のリストは表示される) { "Statement": [ { "Action": [ "s3:ListAllMyBuckets" #ここがないとmanagement consoleからバケット全体が見えなくなってしまう。 ], "Effect": "Allow", "Resource":
AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される | DevelopersIO
AWS ドキュメントに IAM コントロールプレーンとデータプレーンの記述が増えた コンバンハ、千葉（幸）です。 ひとまず以下の絵を 90 秒くらい眺めてください。 眺めましたか？ まだ 30 秒も経ってなくないですか？せっかくなのでもうちょっと見てください。 ……眺めましたね？ 以上でこのエントリの内容は概ね終わりです。読んでいただきありがとうございました。 ちょっとだけ残りが続きます。 IAM レジリエンスのドキュメントに記述が増えてた AWS IAM のレジリエンス（復元力、耐障害性）に関する記述は以下ドキュメントにあります。 Resilience in AWS Identity and Access Management - AWS Identity and Access Management 上記のページは 2022/5/16 に更新されており、その段階で追記された内容は以下エン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS IAMによるセキュリティ・ベストプラクティス（スライド紹介） - ブログ日記
Security Engineering on AWSで役に立つ参考リンク集 | DevelopersIO
IAM Roleの仕組みを追う – なぜアクセスキーを明記する必要がないのか | DevelopersIO
【実録】アクセスキー流出、攻撃者のとった行動とその対策 | DevelopersIO
『GCPのCloud IAMを試してみた』
【AWSセキュリティ】簡易侵入検知のススメ | DevelopersIO
AssumeRoleとPassRoleでクレデンシャル情報を保持しない運用を AWSの自動化したオペレーションに対して生じた疑問「これやったの誰？」
非エンジニアにこそ知ってほしいAWSのアカウント管理 ｜ Developers.IO
AWS IAMポリシーを理解する | DevelopersIO
[アップデート]既存のEC2にIAM Roleを付与できるようになりました！ | DevelopersIO
Automation of Terraform for AWS | メルカリエンジニアリング
IAMのスイッチロールを理解したい | DevelopersIO
TerraformでIAM Policyを書く方法5つ | DevelopersIO
時雨祭 (2015.03) で freeeを支える技術という内容で発表しました - futoase
IAMユーザ本人にMFAを管理してもらうためのIAMポリシー | DevelopersIO
AWSにおけるABACの嬉しさ、辛さを語りました #AKIBAAWS | DevelopersIO
プログラムではアクセスキー/シークレットキーを使わずにRoleを利用する | DevelopersIO
【IAM TIPS】S3バケット毎に権限を分けるためのIAM権限設計 ｜ Developers.IO
AWS IAMリソースの棚卸し方法をまとめてみた | DevelopersIO
AWS アカウントのセキュリティを改善するための 10 個の項目 | Amazon Web Services
MFAデバイスが機能しなくなってAWSアカウントにログインできなくなった場合の対処法 - おれさまラボ
最小権限実現への4ステップアプローチ 前編 | Amazon Web Services