メールへのログイン、仮想マシンのプロビジョニング、CRMプラットフォームへのアクセスなど、どのような作業であっても、アイデンティティおよびアクセス管理（IAM）は業務を支えるデジタルの基盤です。
しかし、組織が成長するにつれて、これらのアイデンティティを保護するための統制は、今日の環境が持つ規模、スピード、複雑さに追いつけなくなることが少なくありません。
この領域でよくある摩擦点の一つが、機密性の高いアプリケーションに対して一時的なアクセス、すなわちジャストインタイム（JIT）アクセスを付与することです。ITチームはしばしば板挟みになります。事業部門は生産性維持のため即時のアクセスを求める一方で、セキュリティチームと監査担当者は、抜け漏れゼロと明確な証跡を要求します。
本記事では、この特定の課題を解決するために設計されたTinesの事前構築ワークフロー、一時的なアプリケーションアクセスを付与を取り上げます。このワークフローは、オーケストレーションによってスピードとセキュリティの両立を支援します。
問題：アクセスの拡大はリスクの拡大
「アクセスを拡大すれば、リスクも拡大する」と、TinesのITオペレーション技術者であるStephen McKenna氏は、最近のIAMオーケストレーションに関するブログ記事で述べています。あらゆる「入社・異動・退職（joiner, mover, leaver）」イベントは、一連の変更を連鎖的に生み出します。
多くの組織では、こうした変更が寄せ集めのシステム上で手作業で処理されています。シングルサインオン（SSO）にすぐ連携できるアプリケーションもあれば、手動でのプロビジョニングが必要なものもあります。
ユーザーがJITアクセスを必要とする場合、たとえば開発者がデバッグのために本番環境へのアクセスを必要としたり、請負業者が特定プロジェクトのために入場権限を必要としたりすると、手動プロセスは多くの場合次のようになります。
- 対応の遅さ：ユーザーがチケットを提出し、アナリストが気づくまでキューに滞留します。
- 恒久的な権限肥大化：アクセスを付与した後、アナリストが解除を忘れることがよくあります。「一時的」なアクセスが恒久化し、攻撃者が悪用できる権限の蓄積につながります。
- 監査の悪夢：誰がいつ承認し、いつ付与され、いつ解除されたのかという証跡が、メール、Slackメッセージ、チケットコメントに散在します。
オーケストレーションがなければ、アカウントは残り続け、権限は積み上がっていきます。
オーケストレーションがITインフラをどう再構築しているか
最新のIT運用チームが、オーケストレーションを使ってキャパシティを管理し、信頼性を高め、燃え尽きることなくインフラをスケールさせる方法を学びましょう。
この実践的ガイドでは、すでにお使いのツールを活用して、手作業のワークフローを予測可能で自動化された運用に置き換える方法を紹介します。
解決策：自動化された期限付きプロビジョニング
一時的なアプリケーションアクセスを付与ワークフローは、JITアクセス要求のライフサイクル全体を自動化します。
Jira Software、Okta、Slackといったツールをオーケストレーションすることで、このワークフローは、アクセスが迅速に付与され、適切に承認され、そして何よりも、期限が来たら自動的に解除されることを保証します。
以下は、ワークフローがどのように動作するかの概要です。
1. セルフサービスの申請 メールやDMを送る代わりに、ユーザーはTines Page（シンプルなドラッグ＆ドロップのWebフォーム）にアクセスします。必要なアプリケーション（例：「AWS Production Console」）、必要なアクセス期間（例：「2 hours」）、および業務上の正当な理由を選択します。
2. 承認ルーティングの自動化 送信されると、Tinesがユーザーの上長またはアプリケーションオーナーを自動的に特定し、その承認者にSlack（またはMicrosoft Teams）でリッチ通知を送ります。このメッセージには申請内容の詳細と、対話式の「Approve」または「Deny」ボタンが含まれます。
3. 即時プロビジョニング 承認されると、ワークフローがOktaへのAPIコールをトリガーし、当該アプリケーションに紐づく特定のOktaグループにユーザーを追加します。これは即時に行われ、IT管理者が手動でクリックする必要はありません。同時に、コンプライアンス目的で承認を記録するため、Jira Softwareでチケットが作成または更新されます。
4. 「タイムアウト」 これが重要なセキュリティ手順です。ワークフローは、ユーザーが指定した期間（例：2時間）の間、「待機」状態に入ります。
5. 自動解除 タイマーが切れると、Tinesが再開してクリーンアップを実行します。Okta APIを再度呼び出してユーザーをグループから削除し、実質的にアクセスを解除します。最後に、Jiraチケットを「Closed」に更新し、セッションが終了したことをSlackでユーザーに通知します。
メリット
このインテリジェントなワークフローを実装することで、次の3つの主要な柱にわたって即効性のある価値が得られます。
- 最小権限の徹底：アクセス解除を自動化することで、「残存アカウント」のリスクを排除できます。アクセスは必要な時間だけ正確に付与され、攻撃対象領域を縮小します。
- 監査対応のコンプライアンス：申請、承認、プロビジョニング、解除の各ステップがJiraに自動記録されます。監査でアクセス制御の証跡を求められても、スクリーンショットをかき集めることなく、単一の信頼できる情報源を提示できます。
- ユーザー体験の向上：ユーザーは数日ではなく数分でアクセスを得られます。管理者が昼休みから戻ってOktaでボタンをクリックするのを待つ必要はありません。
- 効率化：ITアナリストは、グループへのユーザー追加・削除といった反復的な「クリック作業」から解放され、より価値の高いセキュリティ業務に集中できます。
ワークフローの設定
ゼロから始める必要はありません。このワークフローは、Tines Libraryに事前構築ストーリーとして用意されています。
ステップ1：ストーリーをインポート：Tines Libraryにアクセスし、 一時的なアプリケーションアクセスを付与を検索します。「Import」をクリックしてテンプレートをテナントに取り込みます。
ステップ2：ツールを接続： このワークフローは、外部ツールと通信するためにCredentialsに依存します。次を接続する必要があります。
- Okta：グループメンバーシップを管理するため。
- Jira Software：申請と承認を追跡するため。
- Slack：通知および対話式の承認メッセージのため。
ステップ3：Tines Pageを設定： ワークフロー内の「Page」要素を開きます。フォーム項目は、組織固有のアプリケーションに合わせてカスタマイズできます。たとえば、「Salesforce Admin」「AWS Write Access」「GitHub Admin」を一覧表示するドロップダウンメニューを作成できます。
ステップ4：ポリシーを設定： セキュリティポリシーに合わせてロジックを調整します。最大期間を4時間に制限したり、機密性の高いアプリには第2段階の承認を要求したりすることもできます。Tinesは柔軟なので、こうした追加のロジックブロックをキャンバス上にドラッグ＆ドロップで配置できます。
ステップ5：テストして公開： テスト申請を実行し、Slack通知が発火し、Oktaグループの変更が想定どおりに行われることを確認します。検証できたら、Pageを公開し、リンクをチームと共有します。
このワークフローを実際に試すには、無料のTinesアカウントに登録できます。
