ritou です。 Digital Identity技術勉強会 #iddance Advent Calendar 2024 初日の記事です。今年も頑張りましょう。 qiita.com パスキー認証の理想と現実 パスキー(というかFIDO)認証はパスワード認証を用いた脆弱な現状を打破すべく考えられた仕組みです。メディアの取り上げられ方はこんな感じでした。 とても安全で便利な仕組み プラットフォームを跨いだ利用が可能 パスワードを置き換える 1の安全性については技術的に説明されています。最もシンプルな使い方であれば「慣れ」ることで便利さも感じられるかと思います。 2はプラットフォーマーやパスワードマネージャーが頑張っているところです。Appleがいち早く同一プラットフォーム、クロスデバイスな環境における同期を確立、Google Password ManagerはChromeが動作する環境でパス
ACS事業部亀崎です。 GitHub Universe'24 で紹介され、でもそこまで大きく取り上げられていない機能を１つご紹介します。 それが GitHub Immutable Actoinです。 https://gh.io/immutable-actions 現時点ではPublic Previewという状態です。 Immutable Actionsとは 公開されている情報も交えてご紹介しましょう。 github.com github.com みなさんご存知のように GitHub Actionは標準ではGitHub Repositoryを使って提供します。 しかし昨今のSoftware Supply Chain Securityの動向もあり、できる限り外部からなにか不正なものが紛れ込むリスクを減らしたい、そういうニーズが広がっていると思います。 そこで利用されるのがImmutable A
いわさです。 今朝の AWS API のアップデートみましたか。これ。 セキュリティグループを VPC に関連付け出来るようになったらしいのです。 どういうことだろう。VPC 内で共通で適用されるセキュリティグループが登場したのか？と思ったのですが、どうやら別の VPC 内でセキュリティグループを使えるようにするアップデートのようです。 What's New アナウンスも出ていました！ これは驚きですね。 これまではセキュリティグループは VPC に関連付けして作成し、その VPC 内の EC2 や ENI にアタッチする形でした。 異なる VPC 間のセキュリティグループで ID の参照は出来ましたが、インスタンスやネットワークインターフェースへのアタッチは出来ませんでした。 そのため、同じセキュリティグループを別の VPC で使いたい場合は、例えば次のような方法でコピーする必要がありま
「AWS CDKの脆弱性が発覚した」というニュース記事が流れてきたのですが、読んでも不安を煽るだけで何を言っているかよく分からない内容でした。 仕方がないので、脆弱性を報告したAqua Security社の記事を読んでみました。 非常に分かりやすくまとめてくれているので、マスコミのよく分からない記事で不安を感じている方は、原文を読むことをお勧めします。 超概要 見つかった脆弱性は、特定の手順を踏んでしまったCDK用のS3バケットを乗っ取れるという内容のようです。 脆弱性の影響の可能性があるアカウントには、2024/10/15 (日本時間だと2024/10/16かもしれない)にAWSから「Missing CDK bootstrap bucket」がタイトルに含まれるメールが送られています。 メールが来てなければセーフです。(今回の脆弱性に対しては)安全です。安心してください。 メールが来てい
FIDO認証のセキュリティキーとして人気のYubiKeyに脆弱(ぜいじゃく)性があることが判明したと、セキュリティ企業のNinjaLabが発表しました。脆弱性を突いた攻撃には高度な知識と高価な設備が必要ですが、YubiKeyはファームウェアの更新ができないため、バージョン5.7より前の製品はすべて永久に脆弱なままとなります。 Security Advisory YSA-2024-03 | Yubico https://www.yubico.com/support/security-advisories/ysa-2024-03/ EUCLEAK - NinjaLab https://ninjalab.io/eucleak/ YubiKeys are vulnerable to cloning attacks thanks to newly discovered side channel |
この文章はなに? 本文章は、パスワードマネージャーであるBitwardenが公開しているソースコードを読み、そこでE2EE(End-to-end encryption)がどのように実装されているかについて、私が理解した内容をまとめたものです。 「E2EEをぼんやり理解してるが、どのように実装されているのかはわからない」という方を主な対象としています。 E2EEに対する私個人の課題感として、インターネット等から得られる説明が比較的抽象的であり、実装レベルでの理解が難しいというものがあります。 そこで私自身、そして同じ課題感を持つ方に向けて、E2EEを実践しているアプリケーションの1つであるBitwardenを参考に、それがどのように実装されているのかを詳細に理解すべく、本文章にまとめることとしました。 なお対象アプリケーションとしてBitwardenを選んだのは、私自身がユーザーであること、
ウォンテッドリーは7月30日、ビジネスSNS「Wantedly」について、ユーザー約20万人の情報が漏えいしていた可能性があると発表した。同社は4月、アクセス設定の不備による情報漏えいの可能性を発表。その後リスク調査をしたところ、同様の問題がサービス内で10件見つかり、新たな漏えいの可能性が発覚したという。 調査により、2013年10月17日から24年6月10日にかけて、未公開か削除済みの人材募集記事19万4733件、もしくは企業の公式ページ2万4435件が、本来アクセス権限を持たない第三者に閲覧された可能性が発覚。これにより、それぞれのページに載っていたユーザーの氏名や所属企業、職種、プロフィール画像、自己紹介文など20万578人分が漏えいした可能性が明らかになったという。 期間中は人材募集記事や企業の公式ページに対し「公開範囲を超えてブックマークやフォロー、募集に対する応募が可能であり
セキュリティ企業・Binarlyの研究チームが、Acer、Dell、GIGABYTE、Intel、Supermicroが販売する200種類以上のデバイスでブート時に任意コード実行が可能になる脆弱(ぜいじゃく)性「PKfail」を報告しました。脆弱性の起因は、セキュアブートの基盤となるプラットフォームキーが2022年に漏えいしたことと指摘されています。 PKfail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem SupplyChainAttacks/PKfail/ImpactedDevices.md at main
GitHubでは削除されていたりプライベートに設定されていたりするフォークやリポジトリに誰でもアクセスでき、さらにその動作が欠陥ではなく仕様通りであるとオープンソースセキュリティ企業のTruffle Securityがブログに投稿しました。 Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co. https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github GitHubでの一般的なワークフローとして、「新しいフォークを作成する」「コミットする」「フォークを削除する」というものを考えてみます。 この時、削除したはずのフォークの中身を誰でも確認できてしまうとのこと。
証明書認証局(CA)のLet's Encryptが、公開鍵の証明書の失効状態を取得する通信プロトコルであるオンライン証明書状態プロトコル(OCSP)のサポートを終了することを明らかにしました。 Intent to End OCSP Service - Let's Encrypt https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html Let's Encryptのエグゼクティブディレクター兼共同創設者であるジョッシュ・アース氏は2024年7月23日に、「私たちは本日、OCSPのサポートを終了し、証明書失効リスト(CRL)をできるだけ早く導入する意向を発表します」と述べました。 Let's Encryptは記事作成時点で約10年間にわたってOCSPのレスポンダーを提供してきましたが、2022年からはCRLのサポートも行っ
対象読者 様々なプロダクトへ AWS アカウントや環境を提供する SRE / CCoE チームを想定しています。 マルチAWSアカウント環境 SRE / CCoE は各プロダクトが安全かつ便利に AWS を利用できるよう、AWS アカウントの設定・払い出しや周辺コンポーネントの提供（踏み台・ID管理・ログ収集 etc...）を行います。 個別プロダクトの基盤設計や構築は行いません。 私の担当案件では 100 以上の AWS アカウントを提供しています。これでも多いとは言えず、例えば NTT ドコモでは 2,000 以上の AWS アカウントを管理[1]しているそうです。 セキュリティ対応方針 セキュリティグループの全開放や S3 バケットのパブリック公開など、AWS リソースの不適切な設定についての対応を考えます。 ゲート型 IAM ポリシーやサービスコントロールポリシー (SCP) で
セキュリティ研究者のAlexander Peslyak氏(通称：Solar Designer)は7月8日(現地時間)、Openwallのメーリングリストに投稿した「oss-security - Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems」において、特定環境のOpenSSHから脆弱性を発見したと伝えた。これは7月1日に公開されたセキュリティ脆弱性「regreSSHion」のレビュー中に発見された脆弱性とされる(参考：「OpenSSHに管理者権限で任意コード実行の脆弱性、アップデートを | TECH+（テックプラス）」)。 oss-security - Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux system
Democracy is on the ballot. For her future, vote.Everything I know about the XZ backdoor stateevergreeninblogtagsopen-sourcedate3/29/2024This publication was last updated at 12:49 PM EST on April 8th Recently, a backdoor was discovered in XZ, a popular library for lossless data compression. Initial research efforts were predominantly concentrated on unpacking the well-disguised attack vector, whil
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？ 当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介します。 本記事の対象コントロール [StepFunctions.1] Step Functions ステートマシンではログ記録が有効になっている必要があります [StepFunctions.1] Step Functions state machines should have logging turned on 前提条件 本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容です。 AWS Security Hubの詳細についてはこちらのブログをご覧ください。 コントロールの説明 このコントロールは、AWS Step
先日2024/04/16にタイミーさんのオフィスで開催された、AWS知見共有会というイベントで発表してきました。この会のテーマは「運用のスケーラビリティとセキュリティ」ということで、私は「コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える」というタイトルで発表してきています。 イベントの動画もあります。 私の発表は 1:43 ぐらいからです。 この発表については資料と動画を見ていただければ！という感じで特に付け加えることもなかったのですが、イベントの開催後にGitHubから発表された新機能Push rulesがとても便利で、新たなベストプラクティスとなるインパクトがあると思ったので、この記事で紹介します。 Push rulesとは つい昨日発表された機能で、現在はpublic betaという状態です。なので、仕様変更と
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。 計測プラットフォーム開発本部では、複数のプロダクトを運用していますが並行して新しいプロダクトも開発しています。SREチームでは増え続けるプロダクトの運用負荷に対して改善は行っていますが、さらなるプロダクトの拡張に備えてZOZOFITの開発運用を別チームへ移管することになりました。移管作業の中でAWSリソースを別チームが管理するAWSアカウントへ移行する作業が発生することになりました。本記事では移行時に遭遇した課題と、その課題の解決に至るまでの取り組みをご紹介します。 目次 はじめに 目次 背景・課題 調査 ユーザ移行Lambdaの作成 簡易ダイアグラム フローチャート ユーザ移行Lambdaの処理
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
Apple の「Private Cloud Compute」の概要をまとめました。 ・Private Cloud Compute: A new frontier for AI privacy in the cloud 1. Private Cloud Compute「Apple Intelligence」は、iPhone、iPad、Macに強力な生成モデルをもたらすパーソナルインテリジェンスシステムです。このシステムで複雑な推論が必要な場合のために、AppleではプライベートAI処理専用に設計されたクラウドインテリジェンスシステム「Private Cloud Compute」(PCC) を開発しました。PCCは、Appleデバイスのセキュリティとプライバシーを初めてクラウドに拡張し、PCCに送信されたユーザーの個人データがユーザー以外の誰にもアクセスできないようにします。Appleでさえも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く