記事一覧に戻る
guide2026年5月7日13分で読めます

Aikido Endpoint Protection、Mac で1日触ってみた

Aikido Endpoint Protection (以下 EP) を MacBook Air に入れて、マルウェアブロック・ポリシー設定・承認ワークフローを実機で検証しました。動く部分はしっかり動き、運用上気をつけたい点も見つかったので、まとめます。

AikidoEndpoint Protectionハンズオンサプライチェーン攻撃セキュリティ

Aikido Endpoint Protection、Mac で1日触ってみた

Aikido Endpoint Protection (以下 EP) を MacBook Air に入れて、マルウェアブロック・ポリシー設定・承認ワークフローを実機で検証しました。動く部分はしっかり動き、運用上気をつけたい点も見つかったので、まとめます。

TL;DR

  • マルウェアブロックは 403 + 通知 + ログ で完璧に動く
  • エディタ (Cursor / VS Code) はインストール後に再起動 が必要
  • パッケージマネージャーのキャッシュは EP の保護をバイパスする — 運用で気をつけたい
  • Aikido は「EP あれば Safe Chain は不要」と公式に位置づけ

STEP 1: インストール

ダッシュボードの Devices → Connect Device から Mac 用 curl コマンドを取得して実行:

curl -fsSL https://app.aikido.dev/api/endpoint-protection/macos/install/<token> | sh

数秒で完了。続いて macOS の システム設定 → プライバシーとセキュリティ で System Extension の承認 を求められるので許可。これで Devices 画面に Mac が Protected として表示されます。

注意点として、EP インストール後、すでに開いている Cursor / VS Code は再起動が必要 です。エディタ起動時の環境変数や CA 設定が古いままだと、Safe Chain インストール等の操作で SSL エラーになります。

STEP 2: マルウェアブロックの動作確認 (npm)

なお EP のマルウェアブロック機能は Aikido の Free プランでも利用可能 です。組織導入前に個人で試すこともできます。

Aikido が公式 publish しているテスト用 malware パッケージ aikido-endpoint-test (実害ゼロ、検証用に作られた package) で確認:

npm install aikido-endpoint-test
npm error code E403
npm error 403 Forbidden - GET https://registry.npmjs.org/aikido-endpoint-test/...

ネイティブ通知に 「aikido EVENT BLOCKED — aikido-endpoint-test — Malware」、デスクトップアプリの Events タブにも詳細記録。TLS 層でブロック → 通知 → ログ の流れが完全に機能します。

STEP 3: ポリシー設定の動作

EP の Settings ではエコシステムごとに以下のポリシーを設定できます:

  • Block All Installs: 全 install を遮断
  • Force Requests: admin 承認必須化
  • Minimum Package Age: 48時間以内 publish の package を保留

PyPi に対して全部 ON にして、未 install のパッケージ (今回 pendulum) を入れてみると:

pip install pendulum
ERROR: HTTP error 403 while getting 
https://files.pythonhosted.org/packages/.../pendulum-3.0.0-...whl.metadata

ネイティブ通知も 「pendulum — All Installs Blocked」 と、ブロック理由が明示されます。ダッシュボードの Activity タブ にも Install Blocked として記録され、管理者が監査可能。何度 retry しても確実にブロックされ続けることを確認しました。

STEP 4: 承認/拒否ワークフロー

pip install --upgrade pip のような 既存パッケージのアップグレード で試したケースでは、想定通り admin の Inbox に Pending が表示 され、admin が ✓ Approve / ✗ Decline で判断できる動作を確認しました。Decline すると Settings の Packages リストに package が "Blocked" として明示登録され、開発者の再試行は 「Your access request for X has been rejected. Contact your workspace admin for more details.」 と表示されます。

ただし、Block All ポリシー下での新規パッケージ install (pendulum のケース) では、デスクトップアプリで「Request Sent」確認画面まで進んでも Inbox に Pending が出ない挙動が出ました。これが仕様か挙動なのか Aikido に確認中で、回答が来たら追記します。


運用上の注意点 1: pip 側の検証コマンドが現在使えない

Settings → PyPi の test command 欄に pip install safe-chain-pi-test と表示されていますが、実行しても何も起きません:

ERROR: Could not find a version that satisfies the requirement safe-chain-pi-test

Aikido に確認したところ「この package は PyPI から削除済みで、現在 pip 側のマルウェアブロックを直接検証する手段はない」との回答。UI 修正を依頼済みなので近いうちに改善されるはずです。検証は npm 側 aikido-endpoint-test で代替できます。

運用上の注意点 2: パッケージマネージャーのキャッシュは EP をバイパスする

これが今回の検証で一番重要な発見です。

EP は ネットワーク層 (L4 プロキシ + TLS MITM) で package manager のレジストリ通信を傍受してブロックを判定します。一方で npm や pip は、一度ダウンロードしたメタデータや wheel をローカルキャッシュに保存 し、次回以降の install ではキャッシュから優先的に取得します。

# キャッシュクリア後 → ネットワーク経由 → EP がブロック
pip install pendulum --no-cache-dir
# → 403 Blocked

# キャッシュ有効 → ローカルから取得 → EP は介入できない
pip install pendulum
# → "Using cached pendulum-3.0.0...whl.metadata" → install 成功

npm 側でも同様で、npm cache clean --force する前は新しい canary バージョンが install できてしまい、cache クリア後は EP の Min Age フィルタで止まる、という挙動を確認。

つまり EP を新規導入する場合、既存のキャッシュ経由で過去にダウンロード済みのパッケージは Block All=ON でも install できてしまう。EP 導入前にすでに dev マシンに存在する package のうち malware 認定されたものは、EP では止められない、という運用上の前提を理解しておく必要があります。

対処は単純で、EP を入れたタイミングで ~/.npm/_cacache と ~/.cache/pip (および poetry / uv 等のキャッシュ) をクリアする手順を組み込むことです。Aikido にもフィードバック済みです。


Aikido の公式見解: EP あれば Safe Chain は不要

検証の過程で Aikido から確認した重要なポイントは、「EP を導入していれば Safe Chain は別途入れる必要はない」 という公式メッセージングでした。

  • 個人開発者: Safe Chain (無料、CLI ラッパー)
  • 組織: EP (MDM 経由展開、ガバナンス機能込み、Safe Chain 相当の保護も内包)

両方を併用する設計ではなく、EP がより包括的な上位プロダクトという位置づけ。組織導入を検討するなら、Safe Chain を別途 dev マシンに入れる手間や、両者の env 変数 (NODE_EXTRA_CA_CERTS, PIP_CERT 等) の競合を心配する必要はありません。

まとめ

項目評価
マルウェアブロック (npm)✅ 403 + 通知 + Events 記録、UX が明確
Block All / Force Requests / Min Age✅ ポリシー通り動作、Activity に監査ログ
承認/拒否ワークフロー (upgrade 系)✅ Inbox に Pending、admin 承認可能
承認ワークフロー (Block All 下の新規 install)⚠️ 未確認の挙動あり、Aikido に確認中
エディタ再起動⚠️ EP インストール後に必要
pip 側の test command⚠️ 公式 package 廃止済み、修正待ち
package manager の cache bypass⚠️ EP 導入時にキャッシュクリアを推奨

「動く部分はしっかり動く、運用で気をつけたい点が複数ある」というのが偽らざる感想です。組織で導入を検討する場合は、上記の注意点を運用手順に組み込んでおくとスムーズです。

特にキャッシュバイパスの件は EP 導入時にしか気付きにくい運用ギャップなので、本記事として共有する価値があると判断しました。Aikido 側でも対応を検討してくれているので、近い将来は前提が変わる可能性もあります。アップデートあれば追記します。


参考リンク

キーワード

  • Aikido
  • Endpoint Protection
  • ハンズオン
  • サプライチェーン攻撃
  • セキュリティ
A

Aikido Community Japan

公開日: 2026/5/7

最終更新: 2026/5/7

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。