2026年7月18日号

公開された解析では、2.3.26のファームウェアから端末群で共通するRSA秘密鍵を抽出でき、TP-Link IDのメールアドレスは平文、パスワードはソルトなしMD5で保存されていた。さらにポート9999へ認証なしのUDP要求を送ると、精密な緯度経度や端末識別子が返る。位置情報の経路はローカルネットワークだが、工場出荷状態の中古端末でも以前の所有者情報を取得できたという。

調査者は2.4.1で位置情報が応答から除去され、認証情報の保存方式と残存データが改修されたことを検証した。ただし報告は独立研究であり、資産側では端末ごとの適用版を確認する必要がある。カメラ用VLAN、不要な外向き通信の制限、TP-Link IDのパスワード変更、譲渡前の消去確認を組み合わせ、古い端末が残らないよう管理したい。

カスタム指示の参照元がbaseからheadブランチへ変わり、copilot-instructions.md、パス別のinstructions、エージェントスキル、AGENTS.mdに加えてREVIEW.md、GEMINI.md、CLAUDE.mdを読める。実行前処理は.github/workflows/copilot-code-review.ymlへ分離でき、存在しない場合は従来のcopilot-setup-steps.ymlへフォールバックする。

ネットワーク用ファイアウォールは全リポジトリで既定有効となり、Copilotクラウドエージェントとは別に設定できる。ただしセルフホストランナーは対象外だ。導入時は、指示とセットアップファイルの変更を通常コードと分けて保護し、許可先、依存物、秘密情報、レビュー結果の差分をテスト用PRで確認する。

StartStreamSessionへIAMロールARNを渡すと、GameLift Streamsがそのロールを引き受け、S3やDynamoDBなどへアクセスする短期認証情報をアプリへ渡す。標準SDKのコンテナ認証情報プロバイダーを利用するため、従来の長期キー埋め込みや環境変数による受け渡しを置き換えられる。機能はGameLift Streams提供リージョン全体で利用できる。

ロールはストリームグループと同じAWSアカウントに置く必要があり、クロスアカウントのRoleArnは使えない。信頼ポリシーにサービスプリンシパルがなければセッション開始は同期的に失敗する。用途別ロール、S3プレフィックスやテーブル単位の権限、CloudTrail確認、無権限時のアプリ挙動を試してから長期キーを撤去したい。

移行対象は、OpenSearch ServiceのドメインまたはServerlessコレクション上で作成したOpenSearch Dashboardsのテナントと保存オブジェクトだ。移行先は新規・既存のOpenSearch UIワークスペースから選べ、複数テナントを単一ワークスペースへまとめるか、分離したまま複数チームへ割り当てられる。大量の保存済み資産を手で作り直す工程を置き換える。

本番移行では、オブジェクト総数だけでなく、データソース、インデックスパターン、時刻範囲、フィルター、権限、共有URLを代表セットで比較する必要がある。まず複製先ワークスペースで読み取り試験を行い、失敗オブジェクトを記録し、利用者の切り替えと旧Dashboardsの停止を分ける。統合するテナント間の名前衝突も先に洗い出したい。

新しいタグキーはpurposeをDATA_GOVERNANCEとして作成し、BigQuery列へ直接割り当てる。組織で一つの分類を複数プロジェクトやリージョンに再利用でき、値は最大5階層まで継承関係を持てる。タグと関連データポリシーはセカンダリリージョンへ自動複製され、DR時にも同じ分類と制御を持ち運ぶ設計だ。

プレビューでは、タグを付けただけではアクセスは変わらず、そのタグに対するデータポリシー作成が強制の境界になる。既存スキーマをJSONで更新する運用は大量列へ適用しやすい反面、誤った名前空間や未設定ポリシーを見逃しやすい。代表データセットで許可・拒否テスト、継承差分、フェイルオーバー後の権限を自動確認したい。

記事のサイトはWALモードで動き、約4,000行のFTS5検索が5秒かかった際にANALYZEを実行すると大幅に改善した。不要行の削除が5秒を超えると別ワーカーの書き込みがタイムアウトするため、保守処理を小さなバッチへ分けている。約1万行という小さな規模でも、ORMが生成する処理とロック時間を別々に観測する必要がある。

バックアップはVACUUM INTOでスナップショットを作ってresticへ送る方法と、Litestreamの増分複製を試している。ただし復元未検証という制約が重要だ。実務ではANALYZEの実行条件、busy timeout、削除バッチ上限、クエリ計画、バックアップ監視を定義し、別環境への定期復元と整合性確認まで成功条件に含めたい。

新しい企業向けと組織向けのエンドポイントは、日付を指定して1日分のリポジトリ別活動を返す。コーディングエージェントについてはPRの作成・マージ、コードレビューについてはレビュー対象PRとコメント種別別の提案数を集計する。これまでの組織・利用者レベルから、実際に活動が起きたリポジトリへ粒度が下がった。

取得できるのは活動量であり、変更の正しさ、削減時間、レビュー負荷を単独では説明しない。導入前の基準期間を置き、マージ後修正、ロールバック、サイクルタイム、レビューコメント採用率とリポジトリ単位で比較したい。閲覧権限を限定し、欠損日やポリシー変更を記録して、個人ランキングへ転用しないことも重要だ。

実装前のセッションでは、変更理由、ドメイン制約、責務境界、インターフェース、正しさを判断する振る舞いまで詰めるが、編集順や局所的構文は固定しない。長く残る判断はADRなどへ、今回だけのタスク分解はIssueコメントなどへ置く。実装タスクはGit worktreeで分離し、依存関係を準備してから並行させる。

テスト、型チェック、Lintに加え、ブラウザーやAPIによる実動作確認をエージェントへ返せる環境を重視する。PRは実装コンテキストと別のセッションで一次レビューし、人間は要件、設計整合性、認証、決済、個人情報、データ移行へ集中する。ただし設計自体の誤りや若手が判断力を獲得する経路は未解決で、並列稼働率を成果と同一視しない姿勢が必要だ。

新しい対象はUnauthorizedAccess:IAMUser/ResourceCredentialExfiltration.OutsideAWSとInsideAWSで、ECSリソースから作られた短期認証情報が本来の場所と異なる環境で使われたことを知らせる。検証ではFargateタスクの認証情報をAWS外から利用し、Findingの影響リソースにECSタスクロールとFARGATE起動種別、外部IP、実行APIが記録された。

検知は封じ込めそのものではない。アラート後に該当ロールのセッションを無効化し、タスクとイメージを保全・隔離し、CloudTrailの管理イベントと必要なデータイベントを追跡する手順が要る。正規の外部利用がある環境では誤検知の基準を決め、権限を絞ったテスト用ロールで通知経路と初動時間を測定したい。