MicrosoftのAIセキュリティ新戦略「Project Perception」とは? 脆弱性を先回りしてふさぐ次世代の防御:Windowsフロントライン(1/2 ページ) Anthropicの最新AIモデル「Mythos 5」と「Fable 5」が、安全保障上の懸念から騒動を巻き起こしたことは記憶に新しいが、セキュリティ対策の面からMicrosoft内部で活用が進んでいる両技術への対抗、あるいはその延長線上にある技術が話題となっている。 The Information誌が報じているが、Microsoftは7月中にも「Project Perception」と呼ばれるAIを活用したセキュリティ対策ツールの提供を計画しているという。 今回はこのProject Perceptionと、その技術コアになっていると目される「MDASH (Multi Model Agentic Scanning H
こんにちは、Azure Identity サポート チームの長谷川です。 Microsoft Entra ID の認証方法にパスキーを利用する方が増え始めていると思います。パスキーは従来の電話網を利用した認証方法 (SMS や音声通話) などよりもセキュリティ レベルの高い認証方法になるため、多くのお客様にご利用いただきたい認証方法です。しかしながら、ユーザーにパスキーを展開するにあたり、セットアップ手順に不安があるとの声をいただいています。 このため、この記事では、セキュリティ キーを利用したパスキーをセットアップする手順を紹介します。ステップごとにスクリーン ショットを使ったセットアップ手順になっていますので、パスキー展開にご活用いただければと思います。 想定シナリオこの記事では、MFA に利用できる認証方法が何もセットアップされていないユーザーにおいて、PC でセキュリティ キーを利
以下、なぜこの結論になるのかを順に書きます。 そもそもVPC内は盗聴できるのか 最初に確認したかったのは、「物理的に同じLANにぶら下がっていて、他人のパケットが流れてくる」という昔のオフィスLANのイメージが、VPCにも当てはまるのか、でした。当てはまりません。 AWSのVPCは物理的な共有LANではなく、SDNの上に作られた仮想ネットワークです。この「オンプレのL2スイッチング(同じセグメントにフレームが流れ、隣の通信も物理的には見え得る)」と「VPCのSDN(パケットが宛先ごとに個別に転送される)」の違いが、今回の議論の出発点です。SDNとしての全体像はIvan Pepelnjak氏の "AWS Networking 101"(ipspace.net, 2020)が分かりやすく、盗聴の可否に直結する挙動は、AWSのLogical Separation on AWS(ホワイトペーパー)
米国家安全保障局(NSA)は2026年5月28日(現地時間)、ゼロトラスト導入指針(Zero Trust Implementation Guidelines:ZIG)を集約した専用Webページを公開した。ゼロトラスト導入時に利用できる実装指針や技術資料、関連技術の情報にアクセスしやすくし、構築を後押しする。 ゼロトラストは、企業や組織の要件に沿って適用できる柔軟かつモジュール型のセキュリティフレームワークだ。従来の境界防御型モデルを補完する考え方として位置付けられる。 このセキュリティフレームワークは、利用者や端末、システムなど、いかなる主体も初期状態では信頼しないことを前提とする。所在地やネットワーク環境の違いにかかわらず検証を求める考え方を採用し、既存のシステム基盤を活用しつつセキュリティ強化を図る。 ゼロトラスト導入に必要な資料を“ひとまとめ” 新設ページの詳細 新設されたZIGのW
セキュリティ企業のPhishUは2026年5月20日(現地時間)、「Google Password Manager」(以下、GPM)の同期機能を悪用し、利用者のパスキーおよび保存済みパスワード群にアクセスできる攻撃手法「Vaultjacking」を発表した。 Google Password Manager同期機能を悪用 パスキーにアクセスする新手法 PhishUによれば、この手法はWebAuthnそのものを破るものではない。攻撃対象はGPMの同期基盤であり、利用者のGPM PINを取得し、新たな端末として「Googleアカウント」のセキュリティドメインに参加し、同期済み認証情報群を取得する。 GPMではパスキーやパスワードが複数端末間で同期される。同期データは、パスキーや保存済みパスワードを暗号化・復号する共通マスターキー「Security Domain Secret」(SDS)によって保
Microsoftは2026年5月18日(米国時間)、標的組織のクラウド環境を横断して大量の機密情報を窃取した攻撃グループ「Storm-2949」の活動内容をセキュリティブログで公表した。 サイバー攻撃者は「Microsoft Entra ID」の認証情報を起点に「Microsoft 365」「Azure App Service」「Azure Key Vault」「Azure Storage」「Azure SQL」、仮想マシンに段階的に侵入し、複数日にわたりデータを持ち出した。 ID侵害からAzure本番環境に Storm-2949のクラウド横断手口 この攻撃では従来型マルウェアへの依存が限定的だった点が特徴だ。攻撃者は「Microsoft Azure」やMicrosoft 365に備わる正規の管理機能を悪用し、クラウド管理操作に紛れ込みながら権限拡大やデータ取得を進めた。Microsof
DevSecOps (Secure DevOps とも呼ばれます) は、従来の DevOps ライフサイクルのさまざまな段階でセキュリティを組み込むことによって、DevOps のプラクティスに基づいています。 DevOps プラクティスでセキュリティを構築する利点には、次のようなものがあります。 セキュリティ上の脅威を可視化し、脆弱性がデプロイされた環境に到達するのを防ぐことで、アプリケーションとシステムの安全性を高める 開発チームと運用チームによるセキュリティ意識の向上 自動化されたセキュリティ プロセスをソフトウェア開発ライフサイクルに組み込む 開発および設計段階の早い段階でセキュリティの問題を見つけることで、修復コストを削減する DevSecOps が Azure Kubernetes Service (AKS) に適用されている場合、組織の役割によって、セキュリティを実装するための
昨今GitHub上で提供されている有名なOSSに対して攻撃がなされることが多い(例: Nxの2025/08の事例)。自分もそこから学び、最低限GitHub上でセキュリティ周りの設定を入れた方が良いと考えた。 設定を考えるにあたって、とくに次の3つの記事が参考になった。 リポジトリを保護するためのクイック スタート - GitHub ドキュメント Nx の攻撃から学べること #s1ngularity | blog.jxck.io GitHub の Immutable Releases を有効にしてセキュリティインシデントを防ごう これらを参考にAIと協力して最低限のセットアップドキュメントを作ったので共有する。もっとこういう設定を入れるべきなどあれば、教えてもらえると嬉しい。 GitHub OSS セキュリティ最低限セット チェックリスト [ ] Dependabot Alertsを有効化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く