「ID TokenをAuthorization Headerにつけて送る」というお作法について思うところ - r-weblife
こんばんは、ritouです。 ID Tokenがやりとりされている背景 ちょっと前にこんな話がありました。 blog.ssrf.in この id_token が JWT になっていますので、これを Authorization: Bearer $ID_TOKEN というヘッダにして oauth2-proxy で保護されているアプリケーションへ送信するだけです。 docs.aws.amazon.com Authorization ヘッダー (または、オーソライザー作成時に指定した別のヘッダー) に ID トークンを含めます。 この「ID TokenをAuthorization Headerに指定して保護されているっぽいリソースにアクセスする行為」は一体何なのかというお話です。 ある有識者はOAuth 2.0のProtected ResourceをID Tokenで保護することについての投稿をし
OAuth 2.1 の標準化が進められています - Qiita
IETFのOAuth WGでは、今あるOAuth2.0関連の仕様を整理し、一つの仕様としてまとめなおし OAuth2.1 として標準化するとりくみが進められています。 今回は、簡単にOAuth2.1について紹介します。 OAuth 2.0 OAuth 2.0は2012年10月に「RFC6749 The OAuth 2.0 Authorization Framework」として標準化されています。その後、OAuth2.0の改善は続けられ、セキュリティ向上のために利用すべき機能(PKCE)などが追加されているほか、逆に非推奨になっている機能(Implicit Grant)などがあります。 IETFのOAuth WGではOAuth2.0を安全に利用するためのベストカレントプラクティスを「OAuth 2.0 Security Best Current Practice」としてまとめています。 この
AWS IAMの最小権限追求の旅 - プログラマでありたい
皆さん、IAM使ってますか〜？ 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
CVE-2020-10749（Kubernetesの脆弱性）のPoCについての解説 - knqyf263's blog
少し前ですが、Kubernetesの方から以下の脆弱性が公開されました。 github.com タイトルにはCVE-2020-10749と書きましたが、複数のCNI実装が影響を受ける脆弱性でCVE-2020-10749はcontainernetworking/pluginsにアサインされたものです。他にもCalicoはCVE-2020-13597、DockerはCVE-2020-13401、などとそれぞれCVE-IDがアサインされています。 このIssueの説明を読んで、はいはいあれね完全に理解した、と思って一旦閉じました。ですが、頭で分かった気になって手を動かさないのは一番やってはいけないことと念じ続けてきたのに、しれっと同じことをやりそうになっていた事に気づきました。なので数日経ってからちゃんとPoCを書いてみました。多少知識が増えてくるとついうっかりやってしまいがちなので気をつけなけ
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 - Diary
Heroku のデータベースには RDS を使ってよい(あるいはそれが嫌なら Heroku を使うべきではない)という話 Heroku を使うときに問題になるのは、データベースに何を使うかということです。 Heroku 標準の PostgreSQL Amazon RDS ClearDB (Heroku で MySQL を使えるアドオン) などが代表的な選択肢としてあります。ここで Heroku 公式が公開している RDS を使う方法についてのドキュメントを見ると、 RDS のインスタンスをインターネットに全公開して Heroku から接続せよと書かれています。 ネットワーク的な防壁がそろった環境が当然の現代においてこの方針はいかにも許容できないもののように思えます。しかし、ここで ClearDB と Heroku 標準の PostgreSQL について考えてみましょう。 まず ClearD
それなりにセキュアなGKEクラスタを構築する - Qiita
はじめに GKEはGCPのサービスのひとつで、kubernetesのマネージドサービスになります。 GCPコンソールもしくはコマンドラインから、簡単にkubernetesクラスタを構築することができます。 リージョンの設定など初期設定を済ます必要はありますが、以下のコマンドを実行するだけでクラスタ構築が完了します。 趣味で触る場合はさておき、実際に業務でGKEを利用する場合はしっかりとセキュリティ面を考慮する必要があり、そのあたりを意識せずにGKEを利用するのは危険です。 本記事では、GKEのセキュリティに関するドキュメントを参考にし、それなりにセキュアなGKEクラスタの構築方法を紹介したいと思います。本来は最新情報などのキャッチアップも含め本家のサイトを参考にしていただくのが一番です。 このような機能があるんだなと、なんとなくの全体感を掴んでいただければ幸いです。 基本 Kubernet
KeycloakのSAML SSOでGitLabやMattermostにログインする - GeekFactory
KeycloakとGitLabでSAML SSOを設定する方法を説明します。ユーザ管理をKeycloakで行いながら、GitLabやMattermostにSSOできるのでとても便利です。 TL;DR Keycloakはオープンソースの統合ID管理ツールです。OpenID ConnectやSAMLによる認証を提供しています。（こちらの記事が参考になります） GitLabはオープンソースのソースコード管理ツールです。OmniAuth IntegrationでソーシャルアカウントやSAMLによるSSOに対応しています。 KeycloakとGitLabの連携にはSAMLを利用します。 Keycloakの設定 Keycloakで新しいClientを追加します。認証連携したいユーザがいるRealmで作業してください。 Client ID: https://gitlab.example.com *1 C
BeyondCorp Remote Accessを支える技術 #1 GCP Cloud IAP connectorを試してみた | DevelopersIO
ども、ゲストのソラコム大瀧です。 在宅勤務のニーズが高まる昨今、Googleが提唱したBeyondCorp Remote Accessが話題ですね。 BeyondCorp Remote Access | Google Cloud VPNに代わって組織のシステムにセキュアにアクセスする手段をという触れ込みですが、「この製品を使えばBeyondCorp Remote Accessだ！」というものではなく、トラディショナルな境界セキュリティモデルに囚われずよりモダンなセキュリティソリューションを組み合わせてやっていこうというコンセプトモデルであり、Google社内のリモートアクセス構成をお手本にしつつ、日進月歩でその様相は移り変わるものと言えます。BeyondCorpのベースとなるセキュリティモデルであるZero Trust Networkを解説するネットワンさんの記事がわかりやすいです。 新解
パスワードのない未来のための Firebaseで実装するFIDO2 / FIDO2 actualized by Firebase for the password-less future
FIDO（ファイド）はユーザーの認証をローカルで行うため、ユーザーの識別情報がネットワーク上でやりとりされないセキュアなプロトコルです。 ユーザーからのメリットとしてはパスワードを覚える必要がなくワンタップで簡単にログインできますが、実装に関する情報はまだまだ少ないのが現状です。 本トークではサードパーティ認証を使わず、ファーストパーティ認証としてどのようにAndroidアプリにFIDO2を実装し運用していくかについて紹介します。 デモにはFirebase AuthenticationとCloud Functionsを利用します。 サーバーサイドはNode.jsで実装を行います。 https://line.connpass.com/event/173284/
Open Policy Agentを始めてみよう - kenfdev’s blog
www.openpolicyagent.org Open Policy Agent（以下OPA）を最近ちょっとずつ耳にすることが多くなってきた気がします。KubeCon + CloudNativeCon 2017 - Austinで「How Netflix Is Solving Authorization Across Their Cloud」を見たときに「こんな感じに認可を外に出せたらなー」と思った記憶があります。 この記事ではOPAの簡単な紹介と、公式TutorialのGetting Startedを実践した記録を共有します！ OPAとは OPAは汎用的なPolicy Engineと言われています。Policy Engineとは、定義されたルールに従って 判断を下すことができる専門家 です。Policyの中でも「やっていいかどうか（見ていいかどうか）」に関するものが「Access Po
[UPDATE]フェデレーションでタグを渡せるSTSの新機能Session Tagがリリースされました #reinvent | DevelopersIO
こんにちは、臼田です。 みなさん、ID管理していますか？ 今回はIDフェデレーションでIAMを利用している際に、IdPから属性(Attribute)をAWSのタグとして受け取ることができるSession Tagの機能がリリースされたので紹介します。 New for Identity Federation – Use Employee Attributes for Access Control in AWS | AWS News Blog RBACとABAC 良さを知るにはまず背景から。 アクセス制御の方式としてRBAC(Role-based Access Control)がよく使われます。RBACでは、権限を個人ではなくRole(役割)に割り当てて管理する方法で、個人ごとポリシーをメンテナンスしなくて良くなるのでユーザが増えても管理が楽になる仕組みでした。 しかしこれも進んでくると、今度は
![[UPDATE]フェデレーションでタグを渡せるSTSの新機能Session Tagがリリースされました #reinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/098a01a332248d791825217579652e1b7f202bcb/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F12%2Freinvent2019_update_eyecatch.jpg)
GraphQL API を悪意あるクエリから守る手法 - yigarashiのブログ
実サービスで GraphQL API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介
Periodic Background Sync 及び Web を Install するということ | blog.jxck.io
Intro メールクライアントや RSS リーダーのようなユースケースを PWA で実装する場合、バックグラウンドで定期的にタスクを実行したいケースがある。 このユースケースに特化した API として提案されているのが、 Periodic Background Sync(PBS) だ。 しかし、この API を取り巻く議論は「Web にアプリのような API を持ち込む上での難しさ」を物語っている。 この API が Web において正当化できるかどうかは、 Project Fugu に代表される Application Capabilities を Web に持ち込む場合の試金石になりそうだ。 現時点での、仕様、実装、議論について解説する。 Periodic Background Sync Web で定期的なタスクを実行する場合、タブが開いていれば setInterval() などで行う
G SuiteのアカウントをAWS コンソールへ連携させる - Qiita
[完了]をクリックします。 事前構成済みのAmazon Web ServicesクラウドアプリケーションでG SuiteをSAML ID プロバイダ（idp)として選択する Google Adminへ特権管理者としてログインします。 [アプリ] > [SAML アプリ]をクリックします。 下にあるプラス(+)アイコンをクリックします。 リストから[Amazon Web Services]の項目を選択します。 ここでGoogle Idp情報のページから、X.509証明書とIDPメタデータをダウンロードしておきます。 [基本的なアプリケーション情報]ウィンドウの[アプリケーション名]と[説明]の値を入力します。 [次へ]をクリックします。 [サービスプロバイダの詳細]の[エンティティID]、[ACSのURL]、[開始URL]欄に次を入力します。 ACSのURL: https://signin.
Kubernetes Security for Microservices
- Kubernetes Meetup Tokyo #30 ( https://k8sjp.connpass.com/event/171599/ ) で発表した資料です。 * スライド上のリンクはPDFをダウンロードしたらクリック可能です - メルカリではMicroservices化を進めており、各サービスのコンテナをKubernetesクラスタにのせて運用しています。本セッションでは、大規模なKubernetesクラスタを運用するにあたって、セキュリティの観点から、どのような考え方で運用する 必要があると考えているか、セキュリティ戦略を説明します。 【登壇時ビデオ】 https://www.youtube.com/watch?v=5rW0T63A_P8&t=5370 【スライド内主要リンク】 ■攻撃シナリオ チュートリアル https://github.com/rung/tutorial
Cookieのセキュリティを改善する Scheming Cookiesについて - ASnoKaze blog
Chromeが「Cookie の SameSite=Lax をデフォルト化」を進めたことは記憶に新しい。 asnokaze.hatenablog.com Cookieの改善は引き続き議論されており、Cookieの扱いでスキーム（http://やhttps://）を考慮に入れることが検討されている。 Incrementally Better Cookies Cookieのセキュリティ改善を精力的に行っているGoogleのMike West氏は、Secure属性の利用が30%、"__Secure-"プレフィックスの利用が0.18%ほどにとどまっていると述べており(リンク)、セキュリティ改善のためにCookieの扱いを段階的に変更していくことを考えている。 同氏がIETFに提出している「Incrementally Better Cookies」では、Cookieを次のように段階的に改善することを
Zero Trust上から見るか？下から見るか？
複雑なビジネスルールに挑む：正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
機密管理サービス AWS Secrets Manager で RDS のパスワードローテーションを試す | DevelopersIO
こんにちは、菊池です。 先日のAWS Summit 2018 San Francisco では、新しいサービス/機能が多数発表されました。 その中でも、認証情報などの機密情報を管理する AWS Secrets Manager は非常に注目度が高いようです。 【完全新機能】DB認証情報やOAuthキーを一元管理可能なAWS Secrets Managerが発表されました！ この、Secrets Managerを使って、RDSのパスワードを管理・ローテーションを試してみましたので紹介します。 Secrets Manager のRDSパスワードローテーション 前提 実際にやってみてわかったことですが、RDSのパスワード変更はVPC内に起動するLambdaによって実行されます。LambdaがSecret Managerへのパスワード取得・変更と、RDSへの接続・パスワード変更を実行しますので、環境
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitLab as OpenID Connect identity provider | GitLab
Update とは何かそして何であるべきか #cloudnativejp / Cloud Native Meetup Tokyo 2nd
