タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
AWSをはじめとするクラウドプラットフォームの普及に伴い、DevとOpsの境目はかなり曖昧になっています。その中でもIAMの管理は設定によっては権限昇格を引き起こしかねないことから、その管理権限は慎重な管理になりがちです。結果的に、IAMは属人的な管理を行っている組織が多いのではないでしょうか。 …
概要 いまさらだけども理解しているつもりできちんと理解していなかったIAMについて、改めて勉強したので忘れないようにまとめる。 参考にした資料： 【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part1 【AWS Black Belt Online Seminar】AWS Identity and Access Management (AWS IAM) Part2 ※この記事で利用しているSSは上記資料内のものです。詳しく知りたい方は直接元の動画を見てください。 IAMに登場する主な要素 IAMユーザ IAMグループ IAMロール ポリシー IAMユーザ マネジメントコンソールやCLIで利用するユーザ、あるいはSDKでAWSリソースへアクセスするアプリケーションの単位(EC2等で実行す
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。 本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
オペレーション部 江口です。 少し前の話になってしまいましたが、2019年9月に開かれた技術書典7で、「AWS IAMのマニアックな話」という書籍が頒布されました。私も参加して購入、読んでとても良い本だなあ、と思ったのですが、当ブログに書評は投稿していませんでした。 ところが最近、作者の佐々木拓郎氏のTwitterでこんなフリが。 ちなみにサンタさんのクリスマスプレゼントで、クラメソさんがIAMのマニアックな話の書評かいてくれないかなぁと期待しています — Takuro SASAKI＠技術書典-1日目 (@dkfj) December 18, 2019 これには答えざるを得ない。 ということで、この書籍を購入したクラメソ社員として不肖私がレビューさせていただきます。 最初に端的に感想を書いておくと、IAMについて知りたい技術者にとってはまさに必読と言えるでしょう。「マニアックな話」というタ
モブセキュリティで話した内容です。 https://mob-security.connpass.com/event/209884/ 情報の倫理的な取り扱いをお願いします。
AWS（Amazon Web Services）は、AWS IAM（AWS Identity and Access Management）でWebAuthnに対応したことを発表しました。 AWS IAMは以前から多要素認証に対応しており、今回この多要素認証の要素の1つとしてWebAuthnが使えるようになりました。つまりパスワードを入力した上で、追加の認証を行う多要素認証にWebAuthnが加わったことになります。 （2022/6/8 12:45 追記：当初、WebAuthnでパスワードレスなログインが可能と表記しておりましたが、間違いでした。お詫びして訂正いたします。タイトルと本文の一部を変更しました） WebAuthnは、パスワードレス技術の標準化団体であるFIDO Alliance（ファイドアライアンス）が策定したFIDO2仕様の構成要素であるWeb認証技術のことです。 2019年3
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
概要 AWS：IAMについて学んだことをまとめる 学習は Amazon Web Services 業務システム設計・移行ガイド をベース IAM (Identity and Access Management) とは 「どのサービス（リソース）に対する」 「どのような操作を」 「誰に」 許可するか・許可しないかを定義出来る IAM を用いてユーザに権限を付与するまでの流れ AWSサービスやAWSリソースに対する操作権限を「IAMポリシー」として定義する IAMポリシーを「IAMユーザー」や「IAMグループ」にアタッチする IAMポリシー AWSサービスやAWSリソースに対する操作権限をJSON形式で定義したものがIAMポリシー 定義項目 項目 内容
テクニカルトレーナーと学ぶ AWS IAM ロール ~ ここが知りたかった ! つまずきやすい部分を理解してモヤっとを解消 - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「あかねさす柘榴の都」と「クジマ歌えば家ほろろ」です。 今回は IAM ロールの説明を、私なりに感じた「理解する時につまずきやすい部分」を紹介する形式でお伝えします ! これは自身の経験やトレーニングの受講者からよくいただく相談などを踏まえたものなので、今まで IAM ロールの説明を聞いたり読んだりしてきたけどいまいちピンときていない方に、ぜひモヤッとを解消していただきたいです ( ･∀･)=b というのも、私は業務でお客様に AWS の様々なトレーニング を提供しているのですが、AWS Identity and Access Management (IAM) について説明をした後に「トレーニングを受講したことで、今まで難しいと感じていた IAM ロールを理解できた !」と言っていただくことがあります。そのた
AWS IAMの以下のリソースについてどのように考えればいいか - Identity-based Policy vs Resource-based Policy - Permission Boundary - Tag-Based Policy - AWS SSO vs Federated IAM Role
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。 皆さんは定期的にIAMリソースの棚卸しや管理をしていますか？いつの間にか溜まっちゃってる不要なIAMユーザーやIAMポリシーは無いですか？ 不要なIAMリソースを放置することはセキュリティ的に危険です。不要なものは定期的に削除しちゃいましょう。 そこで今回は不要なIAMリソースを少しでも楽に棚卸しする方法をまとめてみました。下記ターゲットに当てはまる方は是非ご一読ください。 本記事のターゲット IAMリソースを管理していない方/出来ていない方 IAMリソースの棚卸しをマネジメントコンソール上から手動でポチポチやって時間がかかっている方 やりたいこと あまり時間をかけずにIAMリソースの棚卸しをしたい 普段使っていないIAMリソースや新規作成したIAMリソースを定期的に確認したい やってみた 今回は以下の3つの
この記事は、 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を通して任意の権限を与えることができるため、管理も非
AWSではいろいろなサービスを組み合わせて情報を守る AWS上に構築したシステム、データを安全に管理するにはどうすればよいでしょうか。 オンプレミスの場合、データセンターにサーバー機器を設置して、設定を行い、インターネット回線を敷設して、やっとインターネット経由でシステムが操作できるようになります。また、勝手にデータセンターに入られて、新たに大きなシステムを勝手に作られるといった心配はないでしょう。 AWS（クラウド）の場合はどうでしょうか。AWSアカウントを作成した直後に、管理者ユーザー（ルートユーザー）でログインして操作を行います。つまり、このユーザー情報が第三者に漏れると、AWSアカウント内で任意の操作を第三者が実行できるようになり、不正アクセスされてしまいます。アカウント作成直後であれば機密情報は無いですが、不正にEC2などのリソースを大量に作成するといったことは可能です。そのため
AWS ドキュメントに IAM コントロールプレーンとデータプレーンの記述が増えた コンバンハ、千葉（幸）です。 ひとまず以下の絵を 90 秒くらい眺めてください。 眺めましたか？ まだ 30 秒も経ってなくないですか？せっかくなのでもうちょっと見てください。 ……眺めましたね？ 以上でこのエントリの内容は概ね終わりです。読んでいただきありがとうございました。 ちょっとだけ残りが続きます。 IAM レジリエンスのドキュメントに記述が増えてた AWS IAM のレジリエンス（復元力、耐障害性）に関する記述は以下ドキュメントにあります。 Resilience in AWS Identity and Access Management - AWS Identity and Access Management 上記のページは 2022/5/16 に更新されており、その段階で追記された内容は以下エン
コンバンハ、千葉（幸）です。 AWS サービスで広範囲の障害が起こったときにどう備えるか？は AWS を利用する上では避けて通れない課題です。 例えば Amazon EC2 であれば、アベイラビリティゾーン（AZ）単位での障害に備えてマルチ AZ 構成にしておく、リージョン単位の障害に備えて別リージョンにバックアップを退避させておく、などの構成が思いつきます。 では AWS IAM で障害が起こったときに備えてどうすべきか？改めて問われると難しい問題です。わたしはぼんやりと「そもそも障害が起こることはないんじゃないか？そもそも AWS IAM における障害って何？」という思いを抱いていました。 そんな折、いつものように AWS IAM のドキュメントの更新履歴を眺めていると IAM のレジリエンスに関する更新が行われていることに気がつきました。 Document history for I
7 年前からが好きだよ AWS 管理ポリシー コンバンハ、千葉（幸）です。 弊社主催のオンラインイベントDevelopersIO 2022の「アルティメットLT AWS愛を語り尽くす！AWS バーサス クラスメソッド 〜むしろお前が好きだよ〜」で AWS IAM AWS 管理ポリシーへの愛を語ってきました。 ここが好きだよ AWS 管理ポリシー 好きなポイントをかいつまんで書きます。 新サービスや新機能の発表の前に作成・更新されていることがある 新サービスや新機能が発表される前から、それらのための AWS 管理ポリシーが作成・更新されていることが多いです。 AWS管理ポリシーの更新をウォッチすることで、「もしかしたらこんなことできるようになるのかな？」という想像が捗ったりします。 数が多い 2022/8/1 時点で 960個以上の AWS 管理ポリシーがありました。推しを見つけたくなります
AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた AWS IAM Identity Center で一時的なアクセス許可を与える仕組みを提供するソリューション Temporary Elevated Access Management (TEAM) が aws-samples で公開されました。例えば、特定の AWS アカウントへの AdministratorAccess 権限のアクセスを利用者が申請し、上長が承認する、といった運用を実現できます。 AWS のブログでも TEAM の使い方が紹介されています。 本ブログでは TEAM ソリューションをデプロイし、AWS アカウントへの一時的なアクセスの申請と承認を試してみます。
LayerX Fintech事業部（※）で、ガバナンス・コンプラエンジニアリングをしている 鈴木 (@ken5scal )です。 ※三井物産デジタル・アセットマネジメントに出向しています。 今回は、AWS IAMポリシーの条件における「ForAllValues」の仕様を誤って理解していたことから、安全でないアクセス制御を実装していたという内容です。もし同様の勘違いをされている方がいたら参考になれば幸いです。 ユースケース AWS IAMユーザーを、ロールの trust policy がユーザーのタグで制御するケースで考えます。 具体的には、「Group A あるいは Group B」に所属し、且つ「Admin」権限のあるユーザーのみが行使できる役割「AdminABRole」があるとしましょう。 この場合、Group と Admin のタグが存在し、下記のようなパターン（※）が考えられます。
ども、ゲストのNTT東日本 大瀧です。 本日IAMロールAnywhereがリリースされました。IAMロールAnywhereは、AWSの認証基盤であるIAMの認証をPKI(公開鍵基盤)に外出しできる仕組みです。本ブログでは、手軽に試せるPKIとしてHashicorp Vaultを試す様子をご紹介します。 動作確認環境 OS : Ubuntu 20.04.4 LTS Vault : バージョン v1.11.0 AWS : 東京リージョン 1. Hashicorp Vaultのセットアップ まずはPKIのCA(認証局)となるVaultサーバーを立ち上げます。Vaultのダウンロードページの [Linux] - [LINUX BINARY DOWNLOAD]で Amd64 のリンクをコピーし、 wget の引数にしてダウンロードします。 $ wget https://releases.hashic
こちらはAmazon EKS #1 Advent Calendar 2019 7日目の記事です。 EKSでIAM RoleをUserAccountに紐付けたり、ServiceAccountをIAM Roleに紐付けたりする際、AWSのドキュメントに従って設定してはいるものの、その設定によって実際にどんな処理が行われているかを具体的に知らない方も多いのではないでしょうか？(私も今回の記事のために調べるまではそうでした。) そこで今回の記事では、Kubernetesの認証認可の仕組みを解説したあと、AWSのIAMの認証情報をKubernetes内のUserAccountに紐付けるaws-iam-authenticatorの動作の仕組みとKubernetesのService AccountにIAM Roleを紐づける仕組みについて設定方法のレベルから一段掘り下げて実際の動作に焦点を当てながら説明
こんにちは。 SRE の @suzuki-shunsuke です。 AWS IAM の管理を miam から Terraform に移行した話を紹介します。 なお、 AWS や miam に限らず「Terraform で管理されていない大量のリソースを Terraform で管理する」ことを検討している方には参考になる内容かと思います。 背景 本ブログでも何度か紹介したとおり、弊社では AWS のリソースを Terraform で管理しています。 しかし、実は IAM に関しては miam という別のツールで主に管理されていました。 miam は AWS IAM を管理することに特化したツールです。 miam には以下のような特徴があります。 Ruby の DSL によって柔軟にリソースの定義ができる miam によるリソース管理を強制できる DSL で定義されていないリソースは削除されて
タダです. terraform-aws-provider 5.68.0 で以下の引用文にあるように aws_iam_role にて inline_policy を使用するのが非推奨になり aws_iam_role_policy が代替先になりました.この記事では,そのリソースの改修を行った備忘録を書きます. resource/aws_iam_role: The inline_policy argument is deprecated. Use the aws_iam_role_policy resource instead. github.com inline_policy から aws_iam_role_policy へ書き換え aws_iam_role のinline_policy を使用していた下記の IAM リソースがあったとします.この状況で terraform plan を試す
PKIベースでAWSのIAMロールを使える IAM Role Anywhereが発表されました。早速使えるようだったのでOpenSSLでCA構築して使ってみた手順を残しておきます。 環境汚さないためにDocker使っています。 AWS Identity and Access Management introduces IAM Roles Anywhere for workloads outside of AWS What is AWS Identity and Access Management Roles Anywhere? - IAM Roles Anywhere Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere | AWS Security Blog [HostOS] RootCA用のDo
2024 年 7 月 31 日 にクラスメソッドの大阪オフィスで開催された DevelopersIO 2024 OSAKA において「AWS IAM Identity Center を使わないマルチアカウント環境のユーザー管理」というタイトルで話しました。 本ブログで資料を公開します。 登壇資料 次の内容について記載しています。 マルチアカウントのユーザー管理の課題 IAM ユーザーの一元管理の基礎 IAM ユーザーの一元管理のテクニック集 AWS Extend Switch Roles を利用したスイッチロール設定の管理 スイッチロールの条件として MFA 有無と送信元 IP アドレスを指定 スイッチロール先 IAM ロールの信頼ポリシーで複数ユーザーをまとめて許可 アクセスキーの利用 AWS CloudFormation を利用した IAM ロールの設定 外部 ID プロバイダとの連携
コンバンハ、千葉（幸）です。 当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の33日目のエントリです。 このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合いいただければ幸いです。 では、さっそくいってみましょう。今回のテーマは『AWS Identity and Access Management (IAM) Access Analyze
Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere | Amazon Web Services
AWS Security Blog Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere AWS Identity and Access Management (IAM) has now made it easier for you to use IAM roles for your workloads that are running outside of AWS, with the release of IAM Roles Anywhere. This feature extends the capabilities of IAM roles to workloads outside of AWS. You can use IAM Roles Anywhere to provide a secu
Authenticate AWS Client VPN users with AWS IAM Identity Center | Amazon Web Services
AWS Security Blog Authenticate AWS Client VPN users with AWS IAM Identity Center September 12, 2022: This blog post has been updated to reflect the new name of AWS Single Sign-On (SSO) – AWS IAM Identity Center. Read more about the name change here. AWS Client VPN is a managed client-based VPN service that enables users to use an OpenVPN-based client to securely access their resources in Amazon We
AWS IAM Identity Center の棚卸しで権限クリープを防ぎたい 初寄稿の @wa6sn です。8/3-4 に開催される SRE NEXT 2024 が楽しみですね。筆者の所属する 株式会社ギフティ も、GOLD スポンサーとしてブースを出しています。ノベルティも配っているので、ぜひお立ち寄りください。 さて本題ですが、今回は AWS IAM Identity Center で付与したアクセス権限の棚卸しについて述べます。SRE をやっていると、こうした AWS アカウントに対するセキュリティ対策に関わる機会も多いのではないでしょうか、ということで書いてみました。なお、筆者の環境では Control Tower を利用して全アカウントで CloudTrail を有効化しつつログを一元保管しているという前提があります。 権限クリープ マルチアカウント運用が広まっている昨今では
本日の発表資料です。AWS IAM の意味論を SMT ソルバに解かせることで、デプロイ前にセキュリティ上の問題を検出するエンジン Zelkova の論文について解説します。 #CICD2021 #CICD2021B 君のセキ… https://t.co/RwhQyMY7Rh
Getting started with AWS IAM Identity Center delegated administration | Amazon Web Services
AWS Security Blog Getting started with AWS IAM Identity Center delegated administration September 12, 2022: This blog post has been updated to reflect the new name of AWS Single Sign-On (SSO) – AWS IAM Identity Center. Read more about the name change here. Recently, AWS launched the ability to delegate administration of AWS IAM Identity Center (AWS IAM Identity Center) in your AWS Organizations or
IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する | Amazon Web Services
Amazon Web Services ブログ IAM Roles Anywhere で AWS IAM ロールを AWS 外部のワークロードに拡張する この記事は Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere を訳したものです。 IAM Roles Anywhere のリリースの通り、AWS Identity and Access Management (IAM) を用いて AWS 外部で稼働しているワークロードに IAM ロールを簡単に使用できるようになりました。この機能は、IAM ロールの機能を AWS 外部のワークロードに拡張します。IAM Roles Anywhere を利用することで、オンプレミスのサーバー、コンテナ、またはアプリケーションが一時的な AWS クレデンシャルを取得
AWS IAM Identity Center を利用して Azure AD のユーザー情報で AWS アカウントへのアクセスを試してみる Azure AD と AWS IAM Identity Center を連携させて、Azure AD の認証情報で AWS アカウントにアクセスする設定方法をまとめました。 Azure AD ユーザーの認証情報を使って AWS IAM Identity Center 経由で AWS アカウントにアクセスする方法を紹介します。以前にも同様のブログを書きましたが、AWS Single Sign-On 時代だったため、改めて書き直しました。手順に変わりがないか確認したい意図もありましたが、ほぼ同じ手順で設定できました。 構成と全体の流れ 構成図と設定内容を示します。 ユーザー/グループ情報の同期は SCIM による自動同期を採用しています。 設定の流れ SA
Amazon Web Services（AWS）は、パスキーがAWS Identity and Access Management (AWS IAM)の多要素認証として利用可能になったことを発表しました。
AWS IAM アイデンティティセンターで、AWS コマンドラインインターフェイス (AWS CLI) と SDK 向けのセション管理機能をサポート
本日より、AWS IAM アイデンティティセンター (AWS Single Sign-On の後継サービス) のお客様は、AWS コマンドラインインターフェイス (AWS CLI) セッションと SDK セッションのセッション時間 (15 分から 7 日) を管理できるようになりました。今回のリリースにより、IAM アイデンティティセンターで組織のアクセスポータルのセッション時間を設定すると、アプリケーションとコンソールのセッションだけでなく、AWS CLI と SDK のセッションにもそのセッション時間が適用されます。 今回のリリースより前は、AWS CLI と SDK のセッションの制限は 8 時間でした。長いセッション時間を設定できるようになったため、再認証を行わなくてもジョブを長時間実行したり、長時間実行しているジョブが突然終了するのを防いだりすることができます。また、組織のセキュ
Announcing new AWS IAM Identity Center (successor to AWS SSO) APIs to manage users and groups at scale
AWS is launching additional APIs to create, read, update and delete users and groups in AWS IAM Identity Center (successor to AWS Single Sign-On). The new APIs expand existing capabilities to help reduce administrative effort and save time, and provide greater visibility into the users and groups that are available in IAM Identity Center. You can use the APIs for provisioning, de-provisioning or u
AWS OrganizationsのAWS IAM Identity Center(旧AWS Single Sign-On;AWS SSO)を利用すると、Organizations配下のAWSアカウントにSSOできます。 本記事では、同機能をAWS CLIから利用する方法を紹介します。 AWS IAM Identity Centerの詳細は次のブログを参照ください。 なお、本記事ではAWS Identity Center directoryでユーザー管理しているものとします。 ポイント IAM Identity CenterにはAWS CLI v2が対応。v1は未対応 設定ファイルはAWS CLIだけでなくAWS SDK全般で流用可能 IAM Identity Centerはリージョナル・サービス IAM ユーザーのように永続的なアクセスキーは存在せず一時的な認証情報を利用 各アカウントへ
AWS IAM が WebAuthn と Safari ブラウザをサポートし、セキュリティキーによる多要素認証が可能になりました
AWS Identity and Access Management (IAM) は、サポートされているすべてのブラウザ全体で、強力でフィッシングに強い認証のための Web Authentication (WebAuthn) 標準をサポートするようになりました。WebAuthn は、FIDO U2FAPI を継承する FIDO2 仕様の一部であり、パブリックキー暗号化に基づくセキュリティキーを用いた安全な多要素認証が可能です。 この機能は、既存の多要素認証 (MFA) 機能を拡張し、最新のインターネットブラウザや FIDO に準拠した認証機能との互換性を確保するものです。Mozilla、Opera、Firefox、Chrome などの主要ブラウザに加え、Safari ブラウザも認証とセキュリティキーの登録に対応しました。FIDO U2F セキュリティキーなど、すでに FIDO 準拠の認証機
この記事は新野淳一氏のブログ「Publickey」に掲載された「AWS IAMがWebAuthnに対応。多要素認証の要素として利用可能に」（2022年6月8日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。 米AWS（Amazon Web Services）は、「AWS IAM」（AWS Identity and Access Management）が「WebAuthn」に対応したことを発表しました。 AWS IAMは以前から多要素認証に対応しており、今回この多要素認証の要素の1つとしてWebAuthnが使えるようになりました。つまりパスワードを入力した上で、追加の認証を行う多要素認証にWebAuthnが加わったことになります。 WebAuthnは、パスワードレス技術の標準化団体であるFIDO Alliance（ファイドアライアンス）が策定したFIDO2仕様の構成要
AWS Single Sign-on (AWS SSO) が AWS IAM Identity Center になりました。マネジメントコンソールで新しい設定画面を見る限り、AWS IAM Identity Center は AWS Single Sign-On の後継サービスの位置づけとなります。ざっくりと変更点を調べてみました。 AWS のブログでも紹介されています。 何が変わったのか 始めにまとめです。 現時点では、技術的な機能は変更されていない sso identitystoreなどの API、名前空間は下位互換性維持のため、変更されていない マネジメントコンソールを確認してみる 新しい設定画面を画面を見てみます。 メニューの構成は、AWS SSO のときからあまり変わっていないようです。関連コンソールとして、AWS IAM サービスへのリンクが追加されているくらいでしょうか。 冒
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
