クラウドインフラは厄介だ。EC2インスタンスが応答しない」または「CPU使用率が高い」というアラートが発せられると、最初のトリアージはしばしば考古学的な発掘のように感じられる。アナリストは、発券システムを離れ、AWSコンソールで認証し（MFAプロンプトの合図）、特定のリソースIDを探し、真実を知るために正しいCLI構文を覚えなければならない。
このコンテキスト切り替えの税金は重い。平均解決時間（MTTR）を延長し、問題の解決よりもデータ収集に多くの時間を費やすアナリストを疲弊させる。
この記事では、CLIを直接ケースに持ち込むことで、この手作業によるデータ収集を排除する、Tinesの事前構築済みワークフロー「エージェントを使用したCLIデータによるAWS問題の調査」を紹介します。
問題：インシデントレスポンスにおける「コンテキストギャップ
多くの組織では、作業が追跡される場所（Jira、ServiceNow）とデータが存在する場所（AWS、Azure、内部ログ）の間に断絶があります。
単純な “調査 “では、多くの場合、以下のような問題が発生します：
- アクセスの摩擦：複数のコンソールにログインし、ロールを想定する。
- 構文の苦労：単純に答えを取得するのではなく、情報を検索するための正しいCLI構文やフラグを理解するのに時間を費やす。
- セキュリティリスク：ステータスをチェックするためだけに、アナリストに本番環境への広範な読み取り権限を与えること。
このような手作業のプロセスは、規模の拡大の敵である。最近の Tinesのケーススタディにあるように、ある大手クラウドファンディング・プラットフォームでは、手作業のスプレッドシートからオーケストレーションに移行することで、パッチが適用されていない脆弱性をわずか90日間で83％削減した。
その教訓とは？「その背後にある平凡な作業よりも、セキュリティ作業に集中すること。
a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.
ITインフラを手作業で運用する隠れたコスト
最新のIT運用チームがどのようにオーケストレーションを使ってキャパシティを管理し、信頼性を向上させ、燃え尽きることなくインフラストラクチャを拡張しているかをご覧ください。
この実践的なガイドでは、すでにあるツールを使用して、手作業のワークフローを予測可能な自動化されたオペレーションに置き換える方法を紹介します。
ソリューション: エージェントによる自動CLI実行
CLIデータでAWSの問題を調査するワークフローは、チケットとクラウド環境のギャップを埋めます。Tinesエージェント（安全な認証情報を使用してAWSにコマンドを送信できる、安全で軽量なランナー）を使用して、インテリジェントなワークフロー内でCLIコマンドを安全に実行し、結果をアナリストに返します。
アナリストがCLIに行く代わりに、CLIがアナリストに来る。
以下は、ワークフローがどのように動作するかの概要である：
1.トリガー– ワークフローは、AWS リソースに関して新しいケースやチケットが作成された時に開始 される。これは、CloudWatchのアラームによって自動的にトリガーされるか、アナリストが異常に気づくことによって手動でトリガーされる。
2.2.エージェントの仲介– Tinesは、お客様のクラウドに直接アクセスする必要はありません。その代わりに、AWSへの読み取り専用アクセスで実行されているTinesエージェントに指示します。これにより、クラウドの認証情報はローカルで安全に保たれます。
3.動的なコマンド生成– ワークフローは、事前に定義されたスクリプトに依存しません。代わりに、”マジック “は、チケットのコンテキストに基づいてゼロから必要なCLIコマンドを構築するエージェントの能力にあります。S3バケットのポリシーを検査する必要があろうが、EC2インスタンスのセキュリティグループをチェックする必要があろうが、エージェントはインテリジェントに正しい構文を形成し、それを実行する。
4.AIフォーマットとエンリッチメント– 生のCLI出力（多くの場合、高密度なJSON）は、人間が素早く解析するのが難しい。ワークフローでは、Tinesの変換機能（またはオプションのAIステップ）を使用して、このデータをクリーンで読みやすいサマリーや表に解析します。
5.ケースの更新– フォーマット化された調査結果は、Tinesのケースまたはお客様のITSMツールに直接追加されます。アナリストはチケットを開き、インスタンスの現在の状態、セキュリティグループ、パブリックIPをすぐに確認できます。
メリット
このワークフローを導入することで、インシデントライフサイクル全体の効率が向上します：
- ゼロタッチのコンテキスト：アナリストは、すでに目の前にあるデータから調査を開始します。収集フェーズ」はなく、「解決フェーズ」のみが存在します。
- 安全なアクセス：若手アナリスト全員にAWSコンソールへの読み取り権限を与える必要はありません。Tinesエージェントが権限を処理し、承認された特定のコマンドのためのセキュアなプロキシとして機能します。
- 標準化されたドキュメント：すべての調査には、まったく同じデータスナップショットが添付されます。これにより完璧な監査証跡が作成され、TinesCasesが自動的にキャプチャします。
- 共同解決：Tines Casesにデータを取り込むことで、チームは「新規または未知」についてリアルタイムでコメント、タグ付け、共同作業を行うことができます。
構築方法
このワークフローは、インテリジェントなワークフローの旅を始めるためのテンプレートとして利用できます。
ステップ 1: ストーリーのインポートTinesライブラリにアクセスし、「エージェントを使用してCLIデータでAWSの問題を調査する」を検索します。Import “をクリックし、テナントに追加します。
ステップ2: AWSクレデンシャルの接続エージェントがお客様の環境とやり取りできるように、Tinesテナント内でセキュアなAWSクレデンシャル（IAMロールやアクセスキーなど）を直接接続します。複雑なインフラ導入や外部ランナーは必要ありません。
ステップ 3: 推奨コマンドの変更テンプレートにはエージェントのガイドとなるコマンド例のリストが含まれていますが、使用できるのはこれだけではありません。このリストを編集してエージェントの動作を制御し、チームの最も一般的なチケットに基づいてより頻繁に使用させたいコマンドを指定することができます。
ステップ4: ケースのフォーマットを確認するワークフローは、ファインディングをTines Casesに送信するようにあらかじめ設定されているため、手動で接続する必要はありません。しかし、Caseのレイアウトを見直し、アナリストに適したものにしてください。最も重要なデータが一目でわかるように、フィールドの順序やAIサマリーの表示方法を調整するとよいでしょう。
ステップ 5: テストと定義ダミーのチケットでワークフローを実行します。エージェントがコマンドを実行し、出力がケースビューで正しくフォーマットされていることを確認します。
結論
ストレスの多い SOC と効率的な SOC の違いは、しばしば “ありふれたタスク “にあります。アナリストがアラートごとにデータを手動で取得しなければならない場合、ノイズに溺れることになります。
TinesとTinesエージェントを使用してこれらのルーチンチェックをオーケストレーションすることで、スクリプトを反転させることができます。チームが必要とするコンテキストを即座に提供することで、実際に組織を保護する価値の高い意思決定に集中することができる。
クラウドファンディングのテック企業が発見したように、インテリジェントなワークフローは単に時間を節約するだけではない。適切に実装されれば、セキュリティ体制を根本的に変えることができるのだ。
Tines Casesがどのように調査データを一元化できるかについては、この製品スポットライトをご覧ください： Tines Cases｜製品スポットライトをご覧ください。このビデオでは、Casesインターフェイスがどのようにデータを統合し、このワークフローによって生成される自動化されたAWSの洞察のための完璧な目的地にしているかを示しています。
Tines がスポンサーとなり、執筆しました。
Comments