![OpenID Connect の JWT の署名を自力で検証してみると見えてきた公開鍵暗号の実装の話 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/aa41146d0101aa089a4f97b3ae1411bba0f57d1d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9T3BlbklEJTIwQ29ubmVjdCUyMCVFMyU4MSVBRSUyMEpXVCUyMCVFMyU4MSVBRSVFNyVCRCVCMiVFNSU5MCU4RCVFMyU4MiU5MiVFOCU4NyVBQSVFNSU4QSU5QiVFMyU4MSVBNyVFNiVBNCU5QyVFOCVBOCVCQyVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MiU4QiVFMyU4MSVBOCVFOCVBNiU4QiVFMyU4MSU4OCVFMyU4MSVBNiVFMyU4MSU4RCVFMyU4MSU5RiVFNSU4NSVBQyVFOSU5NiU4QiVFOSU4RCVCNSVFNiU5QSU5NyVFNSU4RiVCNyVFMyU4MSVBRSVFNSVBRSU5RiVFOCVBMyU4NSVFMyU4MSVBRSVFOCVBOSVCMSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9Yzg2YjM4N2QzYjdkMWQzMWE5Y2ZkZjdmMGU1ZjlmZWM%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBib2J1bmRlcnNvbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NzkzMmJmNzViYzkxNThiOWYzNDNkYzJiZTc2ODhjZWQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D2e91979166247ba923598ea56d9beac2)
本資料は 2020/9/8 の「CloudNative Days Tokyo 2020」の発表資料です。 ■発表動画 https://event.cloudnativedays.jp/cndt2020/talks/26 ■内容 ・コンテナ全般のセキュリティ ・脆弱な設定のKubernetesに対する攻撃 (アプリの脆弱性をきっかけとした悪意のあるPodの作成、権限昇格、などの攻撃の流れ) ・上記に対する対策 ■書籍以外のReference KubeCon NA 2019 CTF: https://securekubernetes.com/ Kubernetes Security for Microservices:https://speakerdeck.com/rung/kubernetes-security-for-microservices/ Threat matrix for Kub
技術選定について最近の私生活や労働を通して考えたことを、つらつらと書き下した文章(ポエム)です。 他者に伝えることではなく、頭の中におぼろげに存在する考えを言語化して客観視することを目的に書いた雑記なので、 誰かにとっては当たり前なことも、誰にも当てはまらないことも書いてあるかと思います。 またここで述べることは、こうやって書き下した時点での僕の考えに過ぎないので、明日僕は全く別の考えを持って行動しているかもしれません。 いわばこれは僕の思考のスナップショットです。 諸々、ご容赦ください。 技術選定そのもの ソフトウェアの開発においては、どこからが開発者の作るものの責務であり、どこからがその下のレイヤの責務であるかを(あるときには能動的な思考より、またあるときには受動的な思考により)明確にする、という知的活動を繰り返していくことになります。 この営みは、開発するソフトウェアに関する前提を定
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」としてまとめています。 この
皆さん、IAM使ってますか〜? 今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。 IAMでのセキュリティのベストプラクティス まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。 docs.aws.amazon.com AWS アカウントのルートユーザー アクセスキーをロックする 個々の IAM ユーザーの作成 IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する 最小権限を付与する AWS 管理ポリシーを使用したアクセス許可の使用開始 インラインポリシーではなくカスタマー管理ポリシーを使用する アクセスレベルを使用して、IAM 権限を確認する ユーザーの強力なパスワードポリシーを設定
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
実サービスで GraphQL API をインターネットに公開する際は、悪意あるクエリに対する防衛が欠かせません。この記事における「悪意あるクエリ」とはサービスに意図的に負荷をかけるクエリのことです。GraphQL では 、木構造や再帰的な構造を利用して、一回のクエリで容易に数百万・数千万件のデータを取得することができます。そのようなクエリを実行してしまうと、アプリケーションサーバーや、その後ろにいる別のサービスに甚大な負荷がかかります。これは攻撃者からしてみれば恰好の的で、なんらか対策を講じる必要があります。 幸いこうした問題はよく知られており、クエリを静的に解析するライブラリがいくつか存在します。しかし、そうしたライブラリをどう使うかといったことはあまり議論されておらず、効果的な対策を行うのは依然として難しい状況だと感じます。この記事では、典型的な負荷の高いクエリとその具体的な対策を紹介
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く