リスト攻撃事案から得られるユーザー周りの設計の学び - Qiita
新規登録やリセット機能を用いたスクリーニングが行われたと思われる事案がよく出てきますが、だんだん拾うのめんどくさくなったのでお暇な方は編集リクエストをください 概要 パスワードリスト攻撃を受けた経緯がニュースになっていました。 対岸の火事ではない、ディノス・セシールを襲った新型リスト攻撃 有料会員限定記事なので見れない人は Googleのキャッシュとかでなんとか この記事をどうぞ。 巧妙化するECサイトへの不正アクセス。セシールの被害は「二重登録防止機能」の悪用が原因 まとめると リスト攻撃を受けた 施行されたメアドは登録済みのものだけだった 内部からの漏洩？はしてないっぽい 登録時に多重登録防止の仕組みがあった 新規登録試行いっぱいあった 攻撃対象のメアド抽出に使われたなこれは というお話です。 このお話に関連する、ユーザー周りの設計時に気をつけてることを書き残しておきます。 攻撃者にも
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
Role Based Access Control Design For MicroServices
This article extends the principles and design of API gateway discussed in the article here API Gateway. RBAC stands for Role Based Access Control. Its an approach to restricting system access to authorized users by using a set of permissions and grants. This approach intends to make the governance of controls between users, vendors and customers efficient. The model is built on a hierarchical rel
Microservices Authentication & Authorization Best Practice
Services require authentication and authorization. In a microservices world you typically have a front-end gateway that manages connections from the outside world which then connect you to back-end microservices to handle the request. How and where you do these two crucial steps depends greatly on your environment and how well you protect the different services. Here are my thoughts on specificall
Authentication and Authorization in Microservices
Microservices Architecture has been gaining a lot of ground as the preferred architecture for implementing solutions as it provides benefits like scalability, logical and physical separation, small teams managing a part of the functionality, flexibility in technology etc. But these benefits come at a cost of simplicity since microservices are distributed the complexity of managing them increases.
Microservices Authentication and Authorization Solutions
Microservices Architecture brings many benefits to software applications, including small development teams, shorter development cycles, flexibility in language selection, and enhanced service scalability. At the same time, many complex problems of distributed systems have also been introduced. One of the challenges is how to implement a flexible, secure and…
マイクロサービス時代のセッション管理 - Retty Tech Blog
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
BeyondCorp - A New Approach to Enterprise Security - - 発明のための再発明
GitHubのを眺めていたら、ORYのoathkeeperを見つた。 これがGoogleが社内で使用している「BeyondCorp」を参考にしているということが書いてあったので、その論文を読んだ。 BeyondCorpとは GoogleがVPNの代わりに使用している、認証・認可のシステム。 人・デバイス・ネットワークなどを基に社内システムへのアクセス制御を行い、ホテルやカフェなどから、Google社内システムへのアクセスができるようになっている。 論文は何個か出されているが、読んだのは、BeyondCorp: A New Approach to Enterprise Security また、GCPのサービスにもなっていて、Cloud Identity-Aware proxyという名前になっている BeyondCorpの仕組み 図にすると、↓のような構成らしい 認証 HRのシステムと結びつい
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
マイクロサービスにおける内部通信の認証について
"Backend Engineer’s meetup ~マイクロサービスにおける認証認可基盤~"の発表資料です。 https://connpass.com/event/142624/
OAuth 2.1
OAuth 2.1 datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10 OAuth 2.1 is an in-progress effort to consolidate and simplify the most commonly used features of OAuth 2.0. Since the original publication of OAuth 2.0 (RFC 6749) in 2012, several new RFCs have been published that either add or remove functionality from the core spec, including OAuth 2.0 for Native Apps (RFC 8252), Proof Key for Cod
It's Time for OAuth 2.1
Trying to understand OAuth often feels like being trapped inside a maze of specs, trying to find your way out, before you can finally do what you actually set out to do: build your application. While this can be incredibly frustrating, it’s no accident that OAuth is actually made up of many different RFCs, building upon each other and adding features in different ways. In fact, the “core” OAuth sp
B2BマルチテナントSaaSの認証にAuth0を使うときに知っておきたかったこと - Sansan Tech Blog
こんにちは、新規事業開発室の加藤です。私たちのチームでは新規事業のプロダクトとしてB2BのマルチテナントSaaSを開発しており、その認証にAuth0を使っています。今回Auth0を初めて使用する中で試行錯誤することが多かったので、最初から知っておきたかったことをまとめておきます。 Auth0とは Auth0はIdentity as a Service (IDaaS) と呼ばれる認証をサービスとして提供するSaaSです。シンプルなID・パスワードによるログインや、Google・Facebookアカウントなどのいわゆるソーシャルログインだけでなく、エンタープライズ向けのG SuiteやAzure AD、SAMLなどのシングルサインオン (SSO) に幅広く対応しているのが特徴です。 なお、Auth0は自社の従業員のID管理にも利用できますが、本稿ではあくまでプロダクト開発者目線で、プロダクトの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Paper Title (use style: paper title)
muCon 2016: Authentication in Microservice Systems By David Borsos
Authentication and Authorization of End User in Microservice Architecture - IOPscience
マイクロサービス時代の認証と認可 - AWS Dev Day Tokyo 2018 #AWSDevDay
マイクロサービスシステムにおける認証ストラテジ
GitHub - ory/oathkeeper: A cloud native Identity & Access Proxy / API (IAP) and Access Control Decision API that authenticates, authorizes, and mutates incoming HTTP(s) requests. Inspired by the BeyondCorp / Zero Trust white paper. Written in Go.
セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
