Aws

概要 CloudFront + ALB + Django 構成では ALB が X-Forwarded-Proto を上書きするため、Django に HTTP 判定されて API レスポンス URL が http:// になる問題。CloudFront の custom_header（X-Forwarded-Ssl）は ALB に干渉されない。Django の SECURE_PROXY_SSL_HEADER をカスタムヘッダー参照に変更。 ソース記事 CloudFront ALB Django HTTPS — 2026-02

概要 main.tf（リソース）/ variables.tf（入力）/ outputs.tf（出力）に分割。大規模化時は modules/ 配下でコンポーネント化。環境ごと（prod/stage）で terraform.tfvars を分離。state lock でマルチユーザーの同時実行防止。 ソース記事 Terraform — 2021-06

Linux を標的とするランサムウェアが新たな段階に入った。イラン系とされる攻撃グループ Pay2Key が Linux 向けに進化し、「Pay2Key.I2P」と呼ばれる新たな亜種を展開している。Morphisec の技術分析をもとに、攻撃の手口、防御機構の無効化手法、そして具体的な対策を整理する。 Pay2Key とは Pay2Key はイラン系の攻撃グループに帰属するランサムウェアで、Fox Kitten APT グループとの関連が指摘されている。従来は Windows を主な標的としていたが、企業のサーバー基盤を直撃する Linux 版が登場し、防御の前提が揺らぎ始めている。 2026年2月には、米国の医療機関で Pay2Key による侵害事例が Beazley Security Incident Response によって対応されている。 Pay2Key.I2P の技術的特徴 設定駆動型の設計 Pay2Key.I2P は単なる Windows 版の移植ではない。JSON 設定ファイルによって動作を制御する設定駆動型の攻撃ツールとして設計されている。ターゲットとするファイルシステムの範囲や暗号化の挙動を柔軟に変更できる。 デュアルアーキテクチャ対応 x64 と ARM64 の両方に対応し、従来の x86 サーバーだけでなく、ARM ベースのクラウドインスタンス（AWS Graviton など）や仮想化ホストも一括で狙うことができる。 root 権限の必須化 侵入後は root 権限を必須とし、取得できない場合は即終了する設計となっている。これはノイズを最小限に抑え、検知を回避するための戦略と考えられる。 防御機構の無効化 Pay2Key.I2P の最も危険な特徴は、Linux の防御機構を体系的に無効化する点にある。 SELinux / AppArmor の無効化 実行時に SELinux や AppArmor を無効化し、強制アクセス制御（MAC）による保護を解除する。これにより、通常であれば制限されるファイルアクセスやプロセス操作が可能になる。 systemd サービスの停止 データベースやバックアップなどの重要なサービスを停止し、ファイルロックを解除して暗号化対象のファイルにアクセスできる状態を作り出す。 cron による永続化 cron エントリを登録してリブート後も自動的に再実行されるようにし、単純な再起動では排除できない永続性を確保する。 暗号化の手法 ChaCha20 による高速暗号化 暗号化アルゴリズムには ChaCha20 を採用している。AES と比較してソフトウェア実装での処理速度に優れる。AES-NI などの専用ハードウェアを持たない環境でも高速に動作する。 ...

AWS DMS Serverless Replication（CDC モード）が OOM（Out of Memory）で failed 状態になり、自動再起動の仕組みが検知できずに長期間停止していた問題について、根本原因と対策をまとめます。 構成 RDS (MySQL) → DMS Serverless (CDC) → S3 (Parquet) DMS Serverless Replication で全テーブルの CDC（Change Data Capture）を実行 S3 に Parquet 形式で日付パーティション付きで出力 EventBridge + Lambda で DMS 停止を検知し自動再起動する仕組みを構築済み 発生した事象 症状 prod 環境の DMS Serverless Replication が failed 状態で停止 エラーメッセージ: Replication out of memory. Stop Reason FATAL_ERROR Error Level FATAL CDC が完全に停止し、S3 へのデータ同期が止まっていた 発覚の経緯 手動確認で発見。自動再起動 Lambda の最終実行は約2ヶ月前で、それ以降は検知されていなかった。 根本原因 原因 1: EventBridge ルールのイベントパターンが不完全 自動再起動用の EventBridge ルールが REPLICATION_TASK_STOPPED のみを監視していた。 ...

AWS が「Agent Plugins for AWS」を公開しました。AI コーディングエージェント（Claude Code や Cursor など）に、AWS のアーキテクチャ設計からデプロイ実行までの能力を組み込むオープンソースのプラグインライブラリです。 Agent Plugins for AWS とは Agent Plugins for AWS は、AWS Labs が開発・公開したオープンソースプロジェクトです。コスト見積もり、Infrastructure as Code（IaC）の生成、デプロイといった AWS 固有のスキルセットを AI エージェントに追加できます。 プラグインは以下の要素で構成されています: Agent Skills: 複雑なタスクをステップバイステップで実行するワークフロー。デプロイやアーキテクチャ設計のベストプラクティスを手順として組み込んだもの MCP サーバー: 外部サービス、ドキュメント、料金データなどへのリアルタイム接続 Hooks: 開発者のアクションに対するバリデーションやガードレール deploy-on-aws プラグイン 現時点で提供されている主要プラグインが deploy-on-aws です。「deploy to AWS」と指示するだけで、以下の 5 ステップを自動実行します: コードベースの分析: アプリケーションの構成・依存関係を解析 AWS サービスの推奨: 最適な AWS サービスを理由付きで提案 コスト見積もり: 推奨構成の月額コストを試算 IaC の生成: CDK または CloudFormation でインフラコードを生成 デプロイ実行: ユーザーの確認後にデプロイ AWS によると、従来は数時間かかっていたデプロイフローが約 10 分で完了するとのことです。 Claude Code へのインストール Claude Code では、プラグインマーケットプレイス経由でインストールします: ...

きっかけ ある日、開発環境の Web アプリにアクセスしたら証明書の期限切れ警告が表示された。 確認してみると、ワイルドカード証明書 (*.dev.example.com) がちょうどその日に期限切れになっていた。さらにもう1つ古い証明書も半年前に失効済み。 Certificate Name: dev.example.com-0001 Domains: *.dev.example.com Expiry Date: 2026-03-17 (INVALID: EXPIRED) Certificate Name: dev.example.com Domains: *.dev.example.com dev.example.com Expiry Date: 2025-09-17 (INVALID: EXPIRED) 原因 certbot の renewal 設定を確認したところ、問題が見えた。 1 2 3 [renewalparams] authenticator = manual pref_challs = dns-01, authenticator が manual になっていた。 ワイルドカード証明書は DNS-01 チャレンジが必須だが、manual モードでは certbot が更新のたびに「この TXT レコードを DNS に追加してください」と対話的に聞いてくる。つまり 自動更新が不可能 な状態だった。 systemd timer (certbot.timer) は1日2回動いていたが、manual モードの証明書は自動更新をスキップされるため、期限切れまで放置されていた。 対応方針 2つの選択肢を検討した。 ...

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計 @suin 氏のポストが、AI エージェント時代の .env 管理問題に対する実践的な解決策として、自作の 1Password CLI ラッパー「opx」を公開しています。 .envをAIに安心して触らせたくて、こんなの作った AIエージェントなしではもう開発が成り立たないほど必須になってきています。権限設定がいろいろできるにせよ、本質的にAIエージェントにはプロジェクトの全ファイルを触りうる力を与えているわけで、気になるのがシークレットなどの機密情報です。 Claude Code や Cursor などの AI コーディングエージェントは、開発者と同じ権限でファイルシステムにアクセスします。.env にアクセストークンや AWS キーを平文で書いていれば、エージェントはそれを読めてしまいます。この構造的な問題に対し、「.env に機密情報を一切書かない」というアプローチで解決するのが opx です。 問題の構造 — AI エージェントが .env を読める なぜ危険なのか AI コーディングエージェントは通常のプロセスとして動作し、シェル環境を継承します。 開発者のシェル └── AI エージェント（Claude Code, Cursor 等） ├── ファイルシステムへのフルアクセス ├── .env ファイルの読み取り ├── 環境変数の参照 └── Bash コマンドの実行 .zshrc に AWS_SECRET_ACCESS_KEY を書いていれば、エージェントもそれを持っています。プロンプトインジェクション攻撃を受けた場合、エージェントが意図せず機密情報を外部に送信するリスクがあります。 実際に報告されている脆弱性 2025年末に公開された「IDEsaster」と呼ばれる調査では、Cursor、Windsurf、GitHub Copilot、Cline など30以上の AI IDE に脆弱性が発見されています。OpenAI Codex CLI では .env ファイルを経由した任意コマンド実行の脆弱性（CVE-2025-61260）も報告されました。 ...

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...

Amazon Bedrock が OpenAI API 互換を提供開始 — Mantle 推論エンジンが「モデルの交換可能性」を実現する @publickey が X で投稿した、Amazon Bedrock の OpenAI API 互換機能に関するブログ記事が話題を呼んでいます。 ブログ書きました： 「Amazon Bedrock」でOpenAI API互換を提供開始。オープンウェイトな基盤モデルでOpenAI SDKが利用可能に Publickey の元記事によると、AWS は Amazon Bedrock の Mantle 推論エンジンで OpenAI API 互換機能の提供を開始しました。これにより、開発者は使い慣れた OpenAI SDK をそのまま Amazon Bedrock 上で利用できるようになります。 この動きは単なる「API の互換性」にとどまらず、AI 業界の構造を変える可能性を持っています。本記事では、Mantle 推論エンジンの技術的な仕組みと、この互換性がもたらす業界への影響を掘り下げます。 Mantle 推論エンジンとは何か 分散推論の基盤 Mantle は、Amazon Bedrock のために構築された大規模モデル向け分散推論エンジンです。単なる API ラッパーではなく、以下の機能を内包する本格的な推論インフラです。 機能 説明 サーバーレス推論 容量管理を自動化し、デフォルトのクォータを引き上げ OpenAI API 互換 Chat Completions API / Responses API をネイティブサポート ステートフル会話管理 会話履歴をサーバー側で保持（Responses API） 非同期推論 長時間実行ワークロードのバックグラウンド処理 ストリーミング リアルタイムのレスポンス生成に対応 ゼロオペレーターアクセス NitroTPM による暗号学的な実行環境保証 セキュリティ設計 Mantle のセキュリティ設計は注目に値します。EC2 インスタンス証明（Instance Attestation）機能を活用し、顧客データ処理のための硬化された不変のコンピュート環境を構成しています。Nitro Trusted Platform Module（NitroTPM）による暗号署名付き証明測定で、モデルの重みと推論オペレーションを保護します。 ...

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。 しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。 4ツールの守備範囲 最も重要な違いは管理対象の範囲です。 ツール 管理対象 DB接続 SaaS キー LLM API キー AWS 認証 aws-vault AWS 認証情報のみ - - - 対応 lkr LLM API キー（8社） - - 対応 - dotenvx .env に書ける全て 対応 対応 対応 対応 1Password CLI 全種類 対応 対応 対応 対応 aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。 各ツールの強みと弱み aws-vault 1 $ aws-vault exec dev -- python manage.py runserver 強み 弱み STS 一時認証（15分〜で自動失効） AWS 認証情報しか管理できない AssumeRole による権限分離 macOS 限定（Keychain 依存） MFA 統合 チーム共有不可 漏洩しても短時間で無効化される 最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。 ...