‍

「デジタルアイデンティティのやさしい教科書」の連載記事です。この連載で認証・認可、権限管理などサイバーセキュリティにおけるアイデンティティの基礎を学ぶことができます。

‍

そもそもアイデンティティとは？ID・アカウントとの違いは？

‍

・IDとは？

IDとは識別子（Identifier）です。システムやアプリケーション内でユーザー、デバイス、プロセスなどを一意（Unique：ユニーク）に識別するための基本情報を指します。IDは、主体（subject：人・デバイス・プロセスなど）がリソース（object：目的となるもの）にアクセスする際に、これらエンティティが「誰（または何）であるか」を検証・確認するために使用されます。

具体的には、ユーザー名、メールアドレス、デバイスID、APIクライアントID、ホスト名などがIDに該当します。IDは認証（Authentication）や認可（Authorization）プロセスにおいて、エンティティを正確に識別する重要な属性として機能します。

‍

・アカウントとは？

アカウントは、システム内でIDに紐付けられた、権限、設定、アクセス情報を管理する単位です。主体がリソースにアクセスできる範囲や操作可能な権限を制御する役割を持ちます。

アカウントには、ID（ユーザー名やメールアドレスなど）を中核に、ロール、セキュリティ設定、ログイン履歴などが含まれます。この情報を基に、システムは主体を正確に識別し、適切な権限を付与します。

また、IDやアカウントと密接に関わる「アクセス管理」の仕組みについては、アクセス管理とは―現代のセキュリティに不可欠な仕組みで詳しく解説しています。

‍

‍

・アイデンティティ（Identity）とは？

サイバーセキュリティの文脈では、アイデンティティとは、IDやアカウントなどを含む広い概念を指します。NISTのデジタルアイデンティティガイドライン（NIST SP 800-63-3）では、以下のように定義されています。

"An identity is the set of attributes that uniquely describe an entity within a given context."（アイデンティティとは、特定のコンテキスト内でエンティティを一意に識別するための属性の集合である。）

例えば、社員番号のような自社でしか通用しないアイデンティティや所属部署という属性もあれば、実名やメールアドレスのように組織外でも通用するアイデンティティもあります。特定のシステムでのアカウントのユーザー名、パスワード、ロール（権限）もアイデンティティに含まれます。

‍

・Identity

役割

ID、アカウント、属性などを含む、エンティティを一意に識別するための情報全体。

例

Name: Taro Yamada Department : business technology Email: taro@example.com

‍

・ID(Identifier)

役割

アイデンティティを一意に特定するための属性。単一の識別子。

例

user123 taro.yamada@example.com

‍

・アカウント

役割

IDにもとづき、システムやIT環境の中でリソースへのアクセス権限や設定を管理する単位。

例

username:user123 Email: taro@example.com Role: Admin

‍

情報システムに関連する事柄で説明すれば、アイデンティティは上記のような定義になりますが、誕生日、家族構成、好きな食べ物、飼っていたペットなど、あらゆるものはアイデンティティを構成する属性であると言えます。いわば、アイデンティティとは、少し哲学的な言い方になりますが、そのものが持つ属性の束のようなものであり、その人やものを形作る認知できる属性の集合体です。実際に、過去には秘密の質問として、好きな食べ物やペットの名前などを認証情報にしていました。これは、多くの脆弱性や問題があったため今では用いられなくなりましたが、確かにアイデンティティの一部に他なりません。

‍

このように、アイデンティティは多面的で曖昧ですが、現代のデジタルアイデンティティの領域においては、標準化されたプロトコルやそれを支える暗号技術によって、システムはそのエンティティの検証可能な属性をもって、主体を識別します。第2章から詳しく解説しますが、現代のシステムでは、主体の主張する属性が検証可能であることが求められます。

アカウントが見えづらくなりがちなシャドーITも、アイデンティティ管理の課題のひとつです。シャドーITについてさらに詳しく知りたい方は、Josys ブラウザ拡張機能によるシャドウ IT の管理もご覧ください。

‍

なぜ多要素認証が主流になったのか？なぜWindows11ではTPM2.0が必須になったのか？パスキーはなぜ普及しようとしているのか？パスワードレス、公開鍵基盤（PKI）、X.509証明書、デジタル署名、ハッシュなど暗号技術はなぜ必要なのかなど、アイデンティティに関する疑問や技術を本連載で明らかにしていきます。

‍

・エンティティとは？

セキュリティやIT関連の用語として、エンティティとは、識別可能な一意のすべての「実体」を指します。エンティティはID（識別子）などの属性（Artribute）情報を持つ箱や束のようなもので、人やデバイスだけでなく、システムやプロセスなど無形のリソースも含まれます。

‍

例えば、ユーザー エンティティは、一意のID（メールアドレスやUUIDなど）や部署・役職・ステータスなどの属性およびロールなどの情報が含まれます。また、デバイス エンティティは、デバイスID、シリアルナンバー、OSバージョン、場所、その他ハードウェアやソフトウェアの構成などの属性を持ちます。

‍

・リソースとは？

本記事では、NIST SP 800-207（Zero Trust Architecture）と同様に、リソースをサーバ、システム、データ、アプリケーション、デバイス、ネットワーク機器など、組織が管理する資産とします。保護すべき対象であり、適切なアクセス制御が必要です。組織のネットワーク内だけではなく、クラウドサービスで管理しているアカウント・データなど、有形無形を含む情報資産も対象です。また、本記事においては、アクセスや操作をする対象として、英単語のObject（目的・目標）と同義として扱います。

‍

NIST SP 800-207（Zero Trust Architecture）

"Resources are the information, data, applications, services, or assets that users or entities request access to." （リソースとは、ユーザーまたはエンティティがアクセスを要求する情報、データ、アプリケーション、サービス、または資産です。）

‍

・コンテキストとは？

コンテキストは直訳すると「文脈」ですが、サイバーセキュリティの分野では、ユーザー、デバイス、システムといったエンティティの属性や状態、環境の変化を相関的に捉えることを指します。コンテキストによって、現在と過去の状況からリスクを判断することに活用されています。

例えば、普段は、日本からあるシステムへアクセスしていたユーザーが、1時間後に突然、ロシアからアクセスしてきました。このコンテキストは、物理的に不可能な速度で移動していることを示しています。アカウントのなりすましなどの不正アクセスのリスクが高く、すぐにアクセスを遮断すべきという判断ができます。

‍

次回は、「デジタルアイデンティティ管理の目的と必要性」について、ゼロトラストに絡めながら解説します。お楽しみに！

ID管理のギャップを解消：連携・コラボレーション・統制

実際のIT環境は、複数のアプリ、チーム、システムにまたがっており、そのすべてを自動化できるわけではありません。今月のジョーシスアップデートでは、特に重要となる「連携」「コラボレーション」「統制」の機能を強化しました。これにより、実業務のプロセスに即したIDガバナンスを実現します。

新機能

初期設定プロセスの刷新によるガバナンスの迅速化

‍

IDガバナンスの開始において、不確実な手順を踏む必要はありません。 刷新された初期設定プロセスでは、ジョーシスの設定手順をステップごとに案内し、即座にガバナンスを開始できる環境を提供します。利用開始初日から、IDおよびデバイス情報の同期、未管理アプリの検出、退職者からのライセンス回収、アプリ棚卸しやワークフローの実行が可能です。 試行錯誤することなく、初日から確実なガバナンスを実現します。

IDプロファイル一元化のためのマルチソースデータ同期

従業員データは、多くの場合システム間で分散しています。IdPですべてのユーザーを管理していても、部署や役職などの主要な属性情報は人事システムが保持している場合があります。 マルチソースユーザープロファイル同期により、複数のシステムを用いてID情報を強化できます。

• IdPをプライマリソースとして維持する
• 人事システム（HRMS）から部署や役職などの不足している属性情報を取得する

また、以下の機能により厳密な管理を実現します。

• システム間のカスタムマッピング
• データの不整合の明確な可視化
• サブソース（HRMSなど）のIDデータ変更に基づくアクセス管理ワークフローの設定

これにより、網羅性とコンテキストを維持した信頼性の高い単一のIDプロファイルを作成し、一貫性のある継続的なガバナンスを保証します。

機能の強化

手動ワークフロートリガーによる柔軟性の向上

‍

手動ワークフロートリガー機能により、自動化だけでは対応できない場合でも、管理者が即座に処理を実行・コントロールできます。  特定のユーザーに対して、入社および退職ワークフローの即時実行、再実行、またはスケジュール設定ができます。本機能は以下の用途に最適です。

• 組織全体への展開前に、少数のユーザーで新しいワークフローを安全にテストする
• エラーや自動化適用漏れの影響を受けたユーザーに対し、アクセス権復旧のためのワークフローを再実行する
• セキュリティリスク発生時に緊急の退職対応を行う
• 人事管理の対象外となる業務委託やインターンなどの臨時入社対応を行う

外部アプリのアクションを自動化するHTTPリクエスト

新しいカスタムHTTPアクション機能により、ジョーシスのワークフローから直接REST APIコールを実行可能です。これにより、退職ワークフローでのServiceNowチケット自動作成や、入社フローでのSlack通知などを自動化できます。 

Jira、Zendesk、Freshdeskなどの既存のITチケットツール内でアクションをトリガーできるため、運用の柔軟性が高まり、トレーサビリティも確保されます。 

管理者は、認証タイプ、ヘッダー、JSONボディを含むリクエストの詳細設定が可能であり、接続テストも即座に実施できます。これにより、技術スタック全体にわたるアクションの自動化を実現します。

アプリ棚卸しのCSVエクスポート

ダッシュボードでの確認にとどまらず、スプレッドシートを用いた詳細な分析や記録保存を行えるよう、CSVエクスポート機能を追加しました。

本リリースより、アプリ棚卸しの結果をUIの表示そのままにファイル出力し、監査対応やレポート作成にご活用いただけます。

 ユーザー詳細、回答内容、タイムスタンプ、表示言語、タイムゾーンなどの情報が網羅されており、追加の工数をかけることなく、効率的なコンプライアンス管理を実現します。

アプリ担当者の招待による連携設定の効率化

‍

組織内のアプリ担当者を招待し、ジョーシス上で安全にアプリ連携を完了できるようになりました。 これにより、管理者がすべてのアプリの管理者権限を持つ必要がなくなり、人事、経理、デザイン部門などが管理するツールの連携をスムーズに進められます。 

招待された担当者には設定用のリンクがメールで送信され、安全に作業を完了できます。連携後は即座にジョーシス上での可視化とガバナンスが可能となります。

新規アプリ連携の追加

‍

ユーザープロファイル データソースの拡充

外部データソースのサポートを拡大し、「freee人事労務」および「マネーフォワード クラウド人事管理」に対応しました。これにより、これらの人事システムから従業員データをジョーシスへ直接取り込むことが可能になりました。

アプリ利用状況トラッキングの対応拡大

新たに20のSaaSアプリについて、利用状況のトラッキングに対応しました。対応アプリは以下の通りです。
Act!, Amazon Web Services (AWS), BambooHR, Bonusly, Contentful, DatoCMS, DeployGate, DigiCert, Direct, Discourse, Egnyte, Figma, Freshcaller, GetAccept, Grafana Cloud, HackerRank, SolarWinds Service Desk, Splashtop, Typetalk, xMatters.

‍

今回のジョーシスラーニングは、株式会社メルカリ IT Service Teamの木村さんをゲストにお迎えして、「GASを活用した情シス業務の超・自動化術」をテーマとして情シス業務効率化のベストプラクティスを解説していただきました。

前編では、そもそもGASとは何かといった基本から、GASを使ったメルカリの活用事例をご紹介します。後半では、ラクスル株式会社 取締役CTOの泉との「自社内製ツールとSaaSの使い分け」に関するディスカッションや、よくあるQ&Aについて解説します。

本コンテンツでは、前編・後編に分けてお届けします。

＜スピーカー＞
木村喜生｜株式会社メルカリ　IT Service Team

GASとは何か？

まずは、そもそもGAS（Google Apps Script）とは何か。GASを使うことで、どんなメリットがあるのか。といったことを中心に解説していただきました。元々、木村さんはエンジニア教育事業で起業された経験を持つこともあり、要点を絞った解説でGASの理解を深めことができます。

GASはGoogleが提供するプログラミング言語

木村さん：Google Apps Script（以下GAS）とは、Googleが提供するJavaScriptベースのプログラミング言語のことです。分かりやすく言うと、ExcelマクロのGoogle版だと認識してもらえれば良いかと思います。GASを使えば、Googleのアプリケーションのカスタマイズを簡単に行うことができます。

もう一点、情シス部門におけるGASの大きな特徴としては、Google Admin APIもすぐに連携できることが挙げられます。つまり、認証のためのコードを記述しなくとも連携できるんです。例えば、Google Admin APIを使いたいときはGCP（Google Cloud Platform）のサービスアカウントを作って、シークレットトークンを発行、認証処理をゼロから書かなくてはいけないので、割と面倒で手間がかかりますよね。

そうしたときにGASを使えば、サービスの部分からAdmin APIを選択し、ノーコードですぐに使うことができます。それによって、エンジニアはコードを書き始めるまでのいくつかのステップを飛ばして使うことができるのがGASのメリットです。

最大のメリットはGoogleアプリで操作する作業の”自動化”

木村さん：GASを使うことの大きなメリットは、GoogleスプレッドシートやGoogleドキュメント、Gmailなど、Googleが提供しているSaaSアプリで操作する作業が基本的にすべて自動化できることです。それによって、定期的に実行するような業務タスクを自動化できるので、手作業による手間が不要になります。

特に、情シス部門では社内ユーザーごとの、外部ツールのアカウント設定だったり、管理だったりがありますよね。ユーザーの数や連携するツールの数が増えれば、その分連携に必要な工数が増えます。

その際に、GASによって連携タスクを自動化すれば、1回でも100回でも、ボタンを1度クリックするだけで処理を完了させることができます。

非エンジニアやプログラミング初学者に最適

木村さん：システム開発経験がない非エンジニアや、プログラミング初学者にとって、GASは最適な言語だと感じています。

一般的に、非エンジニアがイチからプログラミング学習をする際に苦労することは大きく3つあります。1つ目は、作りたいものが見つからないこと、2つ目は環境構築が複雑であること、そして3つ目は学習コストが高いことです。

それに対してGASは、作りたいものが作りやすい、環境構築が不要、そしてベースはJavaScriptと同じなので構文が理解しやすいといった特徴があります。コーディング自体も簡単なので、タイプミスが起きにくく、初心者にありがちな構文エラーに苦しむということも減ると思います。

GASを利用する際に注意したい点

複雑な環境構築を行わずに、手軽に自動化を設計できるGASですが、木村さんによればいくつかの注意点があると言います。GASを使う際に前提として理解すべきこと、そして事前準備について解説していただきました。

GASは問題解決のための一手段

木村さん：GASは、誰でも手軽に自動化を設計できる便利なツールですが、万能なわけではありません。前提として、GASが解決できる部分は仕事の全体像の中でHOW（どう解決するか）の部分だけです。

そのため、WHAT（どこが問題なのか）、WHY（どこに原因があるのか）といった部分はあらかじめ検討しておかないと、GASのパフォーマンスを十分に発揮できないでしょう。

つまり、GASを使えば社内の問題がなんでも解決できるわけではなく、あくまでも問題解決のための手段であるということを理解していただけたらと思います。

そもそもGASを使うことが正しいとは限らない

木村：GASの使用に着手する前には、事前準備としてやらなければいけないことが多々あります。

例えば、アカウント発行の自動化をGASでやるとしましょう。その準備として、アカウントの作り方はどういう流れで進めるのか、プロビジョニングのあり方をどうするのか、といったことを事前に検討する必要があります。

そのため、GASを使う前には、「そもそも何が問題か」をもう一段深堀りして検討する必要があります。むしろ、「GASを使わずに解決できないか？」「理想はどうあるべきなのか」といったように、GASを使用するニーズが発生した時点でGASを使わない方法をあわせて考えるくらいがちょうど良いかもしれません。

そうした意味でいえば、GASを使わざるを得ない時点で、組織上未成熟な部分があると捉えた方が良さそうです。頼り過ぎは良くないですし、なんでもかんでも自動化で解決するというアプローチは、組織の成長を考えるとベストプラクティスとはいえないと感じています。

GASを使わなければならないときこそ、上流工程から見直すことが大切だと感じています。

組織の理想と現実を埋めるのに役立つ

GASを使わない仕組みが作れれば理想ではありますが、実際にはそう上手くいかないということも理解しています。やはり本質的な打ち手には、実施に至るまでに時間を要することがほとんどですし、多くの企業がそうした課題に直面しています。

例えば、システム開発に掛かる経営陣との握りや予算の確保、最優先のシステム対応事項の存在、満たさないといけないセキュリティ要件などによって、なかなか議論が前に進まないといったケースも少なくありません。

こうした理想と現実のギャップを埋めるためにGASは有効なアプローチです。外部ツールを使わなくとも手軽に内製化できるとあれば、予算的な問題はクリアできます。自社に開発リソースが不足している場合でも、GASを使えば非エンジニアでも実行できる自動化を整備可能です。

その他にも、特定の組織だけ例外的に実行したい処理や、集計に時間のかかるKPIモニタリング、ツールを入れるほどではないが手間が掛かるタスクなど、日常業務の中で顕在化する様々な問題解決に役立ちます。

【メルカリ】GAS利用の具体事例

GASを使うことで、あらゆる業務タスクの自動化が実現できます。メルカリでは実際にどういった場面でGASを利用しているのか、具体例を交えて解説していただきました。

事例1：新規入社者のSaaSアカウントの自動発行

木村さん：新規で入社した人の各種アカウントを自動で発行する仕組みを構築した事例です。人事マスタから新規ユーザーの入社申請が入ったら、スプレッドシートに入社者一覧が自動作成されます。そのデータをGASが毎日読み込み、入社4日前の朝4時に各種ツール（oktaやGoogle Workspace、slackなど）のアカウント発行APIが自動的に実行され、その結果をSlack通知とスプレッドシートに記入することまで自動化しています。

事例2：ヘルプデスクのタスク自動集計

木村：2つ目は、ヘルプデスクに届くJiraのチケット（課題・タスク）情報が一覧で溜まるようにした事例です。15分ごとにチケット情報を取得するように定期処理を設定しています。既に存在する情報であれば「更新」。存在しなければ「行を追加」。となるように設計し、常に最新のチケット情報が表示されるようにしています。

この設計で良かったのは、コスト観点の精査をする際など、派遣社員の方のチケット遷移がどうなっているかなどを見ることができ、スタッフごとの生産性管理に役立ったことです。

スプレッドシート自動連携によるツールアカウント管理

木村さん：3つ目は、各種ツールのアカウント情報やデバイス情報を全件取得し、自動更新するように設定しています。当社の場合は、各ツールの情報をそれぞれに対応したスプレッドシート上に取得し、その上で各スプレッドシートを1つのシートに統合するということを行っています。

例えば「Aさん」がどのツールのアカウント情報を持っていて、反対にどれを持っていないのかがひと目でわかるようになります。それによって、退職者のアカウント削除の対応漏れを見つけることが可能になりました。

また、ヘルプデスクに問い合わせが入ったときに、ユーザーの所属チームと入社日がわかれば、どの程度のITリテラシーや社内言語の理解があるかを予想できるため、どれくらい丁寧に説明すべきかといったことまで判断しやすくなります。

その他のポイント

GASの活用による情シス部門の自動化術の他にも、他部門で汎用できるポイントや、組織的にGASを活用する際の注意点を解説していただきました。

CSVをエクスポートする手間・時間を削減

木村さん：GASを使えば、データの集計を自動的に行ってくれるため、わざわざ手動で確認する手間やCSVファイルにエクスポートする手間が不要になります。

例えば、メルカリの情シス部門では、各ツールでの休眠アカウントを削りたいといったニーズがあり、そうしたときに、ユーザーごとに各ツールの最終ログイン日を確認しにいくのは非常に手間がかかります。1週間後に見直したら、最終ログイン情報が変わっているといったことも起きるかもしれません。

こうしたアカウントの棚卸しの際にGASを使えば、自動でデータを収集してくれます。その結果、どのツールを現在何人が使っているかといったような質問を受けた場合でも、わずか数分で回答できるのです。

その他、当社の例でいえば「人事マスタにいないのにGoogleアカウントがアクティブなユーザーはどれか？」であったり、「PCを持っている業務委託の一覧を出してほしい」といった問い合わせにも対応できています。

またヘルプデスクとしては、依頼者の所属チーム、入社日、利用端末、権限タイプなどを即時で把握できるため、それによって相手のITリテラシーを推し量ることが可能です。

自動化による運用効率化を進める中で見落としがちな「設定ドリフト」。その対処法を知りたい方はよくある構成ドリフトの5つの課題と対策もご覧ください。

‍

情シス以外にもあらゆる部門で効率化の手段に

木村さん：GASは情シス部門以外にも、さまざまな業務で活用できます。例えば、労務部門であれば、有給日数が残っているメンバーに対して、有給残日数を自動で通知するようなことも可能です。

その他にも、法務部門の反社チェックの自動化、カスタマーサクセスであれば各種メトリクスの可視化、セールス部門であればSFDCとの連携など、定期的に行う業務を自動化させることができます。

基本的に定型業務の自動化に役立つため、まずは自部署で何が問題になっているか、どこに原因があるかを上流から捉えた上で、GASを使って効率化できないかといったことを考えると良いと思います。

セキュリティ管理を徹底する重要性

木村さん：GASを使って個人情報などセキュリティリスクがあるものを扱う場合は、あらかじめセキュリティポリシーを作成することが必要です。

具体的には、個人情報の入ったシートのデータを外部に通知させない対策や、セキュリティ部門と連携する情報資産台帳に登録して、十分にテストするなどレビュープロセスを設けるなどが挙げられます。

こうしたことを確実にやらないと、社内の個人情報が外部の関係者宛に通知されてしまうなど、情報漏洩事故が発生するリスクもありますので、注意していただきたいポイントです。

想を描き、そこに対するギャップを埋める作業をすることに尽きると思っています。

あえて手作業を残すことも大切

木村さん：ここまでGASについて、当社の取り組みも含めて伝えてきましたが、何でもかんでもGASに頼るのではなく、あえて手作業を残すことも大切だということを最後に伝えたいです。

というのも、自動化を進めすぎると、今度はその自動化がちゃんと動作しているのか不安になってくるんです。例えば、手作業の場合、「自分の手でちゃんとやった感」が得られるのですが、それが自動化によって無くなってしまうんですね。

その結果、「エラーが起きていないか」といった不安な気持ちが生じてしまい、せっかく自動化したのに、手作業でダブルチェックをしていては本末転倒ですよね。そのため、あえて自動化しないポイントを残すことであったり、チェック作業そのものを自動化（2段階の自動化）することが大事だったりします。

GASとSaaS管理の組み合わせに興味がある方は、Josys ブラウザ拡張機能によるシャドウ IT の管理も参考になります。

まとめ

今回は、情シス業務の自動化・効率化に役立つGASの活用術について、GASの基本から具体的な活用事例を紹介しました。実際の自動化施策がどう展開されたのか、より実践的な手法についてはGASの活用方法【メルカリの情シス業務の超・自動化術とは】で詳しくご紹介しています。

後編では、ラクスル株式会社 取締役CTO 泉とのディスカッションの様子を展開していきますので、あわせてご覧ください。

【後編はこちら】

‍