※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント(ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー)の作成、安全な取り扱い、
伝統の継承か、時代の変化か。 自民党で激論が交わされている「選択的夫婦別姓」。 議論が活発化した背景には、保守色が強かった安倍政権から菅政権へ移行したことに伴う党内のパワーバランスの変化があるとの見方もある。 衆議院選挙を控える中、いま、自民党内で何が起きているのか。 「氏制度」をめぐる攻防から読み解く。 (中村大祐、宮内宏樹、古垣弘人) 党内で真っ向対立 賛成の立場の議員 「別姓が嫌な人は同姓でよいのだから、選択制にするべきだ」 「通称使用の拡大では限界があり、法的な安定性がない」 慎重な立場の議員 「夫婦別姓では日本の伝統や家族の絆が失われる」 「旧姓の通称使用の拡大を目指すべきだ」 4月2日、自民党本部の7階の会議室。 選択的夫婦別姓を含む「氏制度」を議論する作業チームの初会合が開かれた。 60人を超える議員が詰めかけ、予定を上回る1時間半にわたって議論が展開され、あわせて23人が発
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
少し早いですが、メリークリスマス!事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますドキドキ 目標 本記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 本スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利
2021.01.21 年末にシンガポールに出張しました。 シンガポールでは、行政にデジタル技術を活用しています。 シンガポール国民ほぼ全員が、自分のスマホから行政手続き用に統一されたサイトにアクセスし、そこからパスポートや運転免許証の更新をはじめ、さまざまな行政手続きができるようになっています。 シンガポールでは、個人のスマホが国民のID番号に紐付けされています。 番号登録されている自分のスマホから行政の統一サイトにアクセスすると、スマホのカメラで顔認証され、本人であることが確認されます。 パスワードを覚える必要もありません。 スマホを持っていない人はどうするのかと聞いたところ、低所得者には政府が助成してスマホ又はタブレット又はパソコン(学生・児童の有無、年齢等により異なる)を持ってもらっているとのことです。 使い方がわからない人には地域の公民館のようなところにサポートする人がいます。研修
TL;DRクラウドネイティブな時代のビジネスではWebサービス活用は必須Webサービスをセキュアに利用していくには管理やセキュリティ面での工数・コストが増えるこの工数・コストを下げることこそがWebサービス活用推進ひいてはビジネスの加速に繋がる工数・コストを下げる為に導入するWebサービスにSAML/SSOは必須ログインをSAML/SSOに限定出来ることまでがマストWebサービス利用におけるセキュリティ面で一番重要なのがID周り個々のWebサービスのセキュリティ対策よりもID管理に特化したシステムに任せた方がよっぽどセキュア(餅は餅屋)Webサービス導入時には値が張ってもSAML/SSO出来るプランで契約するSAML/SSOが出来ないことによるデメリット(工数・コスト)の方が、SAML/SSOを有効にできるプランにアップグレードする費用に勝るB2BのWebサービスを提供する企業は全プランに
●イベント概要 「ゼロトラスト超入門」の著者、岡村慎太郎さんによるゼロトラスト勉強会を開催します! ゼロトラストとは? ゼロトラストとは、組織境界の内外の存在を常に「信頼してはならない」という前提に立って、情報セキュリティの方針と実装を規定する考え方です。 「ゼロトラスト超入門」とは 近年、企業のビジネス上の様々なアプリケーションは、それ自体も、それを利用する側もロケーションが多様化しています。かつてのように「社外」「社内」といったゾーンを設けて、境界によってセキュリティを形成することは、もはや意味がありません。ゼロトラストはロケーションに依らず、常にアクセスをチェックし、動的なポリシーによってアクセスコントロールを行います。本書はそんなクラウド時代のセキュリティ戦略の基礎と、GoogleのBeyondCorp®におけるゼロトラストの実践を解説した一冊です。 ●自己紹介 ・スタディスト ・
企業の情報システムにおいてクラウドサービスの採用やリモートワークが一般化するにつれ、「ゼロトラストセキュリティーモデル」(以下、ゼロトラスト)が注目を集めるようになってきた。ゼロトラストはあくまでもコンセプトであって、厳密な定義は存在せず、特定の製品や技術を指すわけでもない。「実態が分かりにくい」「何を基準に製品やソリューションを検討すればいいか分からない」と感じる人も多いだろう。 そこで今回は、実際に企業の情報システムにゼロトラストを組み込む際に、製品やソリューションを選ぶポイントを見ていく。ゼロトラストは広範囲の技術要素を含む概念だが、筆者は大きく4項目にポイントを整理できると考えている。 認証、ネットワーク、モバイル、ログ――4項目のポイントを押さえる まず、ゼロトラストを提唱し始めた米国の市場調査会社Forrester Research(フォレスターリサーチ)が2018年に公開した
現在私は barista という OpenID Connect と OAuth2.0 に準拠したID製品の実装を行っています。 また、私の所属する事業開発部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。 barista チームの増員や、prismatix の認可についての理解を促進するため OAuth 2.0 をある程度しっかりと理解しているメンバーを増やしたかったので、勉強会を開催しました。 勉強会の内容 概要 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を全員で輪読 OIDC 編はこのあとやる予定 攻撃編もやりたい RFC 読んだりもしたい 参加者全員が以下を満たすことが目標 OAuth 2.0 の意図を理解
Azure AD DSとAD DSの比較(Azure ADもちょこっと) 2020.10.15 Office 365 Windows Server Active Directory, AD DS, Azure Active Directory, Azure AD, Azure AD DS, dns, Windows Server, 信頼関係, 比較, 違い 本記事について 本記事は、クラウド製品であるAzure Active Directory Domain Serviceと、オンプレミス製品であるActive Directory Domain Serviceについて比較した記事です。 おまけで、Azure ADについても記載したものです。 概要 デバイスや、ユーザー、サービスなどを管理する、Active Directory(AD)は、Azure上にあるActive Directoryを使
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR(長すぎて読みたくない) 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
こんにちは、2019年7月よりトレタにJOINした @aibou です。 本記事はトレタ Advent Calendar 2019の16日目の記事です。 趣味はNFL観戦とボルダリングです。NFLは今年11月にマイナス気温の屋外で現地観戦してきました。 最近リードクライミングの講習を受けまして、ガシガシと岩を登っております。 さて、今回はAWSアカウントとAWS SSOのお話をしようと思います。 既に社内エンジニアへの共有や社内WikiにAWS SSOの利用マニュアルを残していますが、経緯や変遷について記載していないので、トレタ社員の方にも読み物として読んでいただければなと思っています。 免責事項 本記事を参考に実施したことで発生した金銭・セキュリティ等あらゆる問題について責任を負いかねますので、自己責任のもと実施していただくよう、よろしくお願いいたします。 また、誤り等あればはてブ等でご
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます アイデンティティ管理とアクセス管理の関係 アイデンティティ管理とアクセス管理は大きく関わりあうものです。 アイデンティティ=ユーザIDと考えてみましょう。そうすると、IT環境にアクセスする際には必ずユーザIDを使用してリソースにアクセスするため、この管理が重要であることがわかります。 また、アクセス制御、すなわちアクセスの許可/拒否はセキュリティポリシーに基づいて実施する必要があります。アクセス制御はIT環境の統制を取るために必須の機能であるため、アクセス管理も近年重要視されています。アクセスの設定・制御は、言い換えればユーザIDに対するアクセス権限の付与/剥奪ですから、アイデンティティ管理とアクセス管理を組み合わせて運用していくことが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く