従業員が退職した場合、使用していたソフトウェアアカウントを取り戻し、既存のアカウントを別の従業員または従業員に再割り当てするなど、SaaSアカウントを管理する必要があります。退社した従業員のアクセス権を直ちに取り消すことで機密情報の漏洩を防ぎ、退職した従業員のアカウントを無効化することでライセンスを無駄にすることなくコストを削減できます。さらに、退職した従業員が使用していたSaaSアカウントを他の従業員に再割り当てして効率を向上させることができます。

上記の情報は、企業のIT管理者、セキュリティ担当者、および人事担当者に適用されます。退職した従業員のアカウントを即座に無効化することでセキュリティ上の問題を防ぎ、ライセンスを管理してコストを最適化し、必要なアカウントを新入社員に割り当てるなどします。

この記事では、IT管理の仕事をしている人が、これが当社でも起こっているかどうかを確認する必要がある実際の例を紹介します。それでは、退職時にSaaSアカウントの削除・管理が得意と誤解されやすい3つの事実を見てみましょう。

‍

全従業員の 31% が今も企業の SaaS にアクセスしている

ニューヨークを拠点とするソフトウェア企業DoControlは、従業員が1,000人を超えるさまざまな業界の企業のSaaS環境を分析しました。」2024年のSaaSデータセキュリティの現状」によると、全企業の 31% が、退職した従業員はSaaSアプリケーションに保存されている資産にアクセスできたと答えています。

パンデミック以降、クラウドとSaaSの使用率は急速に増加し、従業員はいつでも複数のアカウントや機密データにアクセスできます。アカウントとユーザー権限が適切に管理されていないと、データ漏えいにつながる可能性があります。退職者の場合、アカウントや関連情報は原則として処分するのが正しいですが、事業継続などさまざまな要因により、便宜上放置されているケースは少なくありません。セキュリティ上の脅威から事業を守るためには、アクセス権の剥奪やアカウントの削除など、SaaS アカウント管理を適切に行う必要があります。

アカウントを作成して割り当てた後に従業員が退職した場合は、その従業員が使用していたアカウントをすべて削除するなど、権限を必ず取り戻すことが重要です。SaaS アカウントを付与するプロセスが決まっていれば、SaaS 管理はうまくいっていると考えがちですが、IT 管理者が手動で処理した場合、削除できないアカウントやライセンスが存在する可能性があります。

実際、Megazone Cloudの既存顧客約300人を対象に実施した「SaaS管理状況調査」では、回答の半数以上が「アカウント付与時に設定したプロセスに従ってうまく管理している」という回答でしたが、約50％が「SaaSの利用状況は簡単には把握できない」と回答しました。つまり、アカウント割り当て後は、ライセンス、アカウント数、SaaS 1台あたりのコストがうまく管理されていないことが分かります。結局のところ、問題はアカウント管理を「ツール」ではなく「プロセス」にしたいということだと推測できます。

‍

確立されたプロセスに従ってSaaSを管理するのが得意であることに関する3つの誤解

スプレッドシートで管理する場合

アメリカのSaaS管理プラットフォーム企業Zyloが発行」2024年のSaaSマネジメント・インデックス」によると、企業の70％がスプレッドシートを使用してSaaSを管理しています。IT プロフェッショナルは SaaS アプリケーションの管理にスプレッドシートを使用するのが一般的です。これは、スプレッドシートを使用する方が IT 管理ソフトウェアを使用するよりも短期的には経済的に感じられ、慣れているためです。

[代替テキスト= 企業が使用しているSaaS管理ツールに関する調査結果]

‍

ただし、スプレッドシートには本質的に制限があります。スプレッドシートは作成された瞬間に古いデータになり、リアルタイムデータを一目で確認したり処理したりすることはできません。データ量が増えると、管理が難しくなります。メンテナンスには多大な労力がかかり、非効率的です。さらに、データサイロが発生しやすく、関連部門間のコラボレーションや効果的な意思決定が妨げられます。

あなたの会社が最初に SaaS を採用し始めたなら、スプレッドシートで SaaS を管理するだけで十分だったかもしれません。もちろん、SaaS をまったく管理しないよりも、SaaS アカウントと使用状況をスプレッドシートで追跡する方がよいでしょう。ただし、スプレッドシートには SaaS の使用状況の概要は記載されていません。

SaaS ごとに毎日権限が割り当てられ、削除される場合

従業員を雇用する際には、その社員が使用しているSaaSを関係部署別に調査します。SaaS A の許可を求め、ライセンスを確認してから許可を付与します。SaaS B にも許可が要求され、ライセンスが確認された後に許可が付与されます。SaaS C、D、E...従業員ごとに必要な SaaS ごとに権限の割り当てを繰り返します。

会社を辞める手続きはどうなっていますか？同様に、権限の取り消しも SaaS ごとに 1 つずつ繰り返す必要があります。SaaS ごとに、管理者アカウントにアクセスして権限を 1 つずつ割り当てたり削除したりします。この時点で、すべての権利が適切に回復され、データが漏洩していないことを確認できますか？そもそも SaaS ごとにレコメンデーションの割り当てと削除は手動で行われているため、ヒューマンエラーが発生する可能性が高く、セキュリティポリシーを一つずつ適用することには限界があります。

管理するSaaSの数が少ない場合、IT担当者は設定されたプロセスに従って管理できるかもしれませんが、SaaSの数が増えるにつれて、手動による管理方法は非効率になることは間違いありません。

SaaS 管理がアカウントの作成、割り当て、削除に限定される場合

退職者が使用していたすべての SaaS アカウントを削除しても、連結アカウントは削除されないため、問題が発生します。その一例が AWS IAM (ID とアクセス管理) です。IAM は AWS リソースへのアクセスを安全に制御できるウェブサービスで、AWS アカウントを作成すると IAM が作成されます。退職した従業員の AWS アカウントは削除されますが、IAM では削除できない場合があります。この場合、退職者がIAM経由で接続してビットコインをマイニングする場合など、サーバーコストが1日あたり1,000万ウォンになるケースもあります。

整理されていないアカウントや有効期限のないアクセスキーは、コストボムや情報漏えいなどの重大なインシデントにつながる可能性があります。 POP (POP) は、IT 担当者を AWS IAM 管理から解放するロールベースのアクセス (RBAC) です。 開発者、エンジニア、デザイナー、オペレーターなどの必要な役割を登録し、各職務の責任者に役割を割り当てます。管理者は個人に発行されたアカウントを管理する必要がなくなり、実務者は POPs Launcher ロールを 1 回クリックするだけで AWS にアクセスできるようになります。

<PoPs Launcher에서 RBAC 기반으로 AWS Console에 로그인하는 화면>

[代替テキスト=POPS (POPS) がロールベースアクセス (RBAC) で SaaS アクセスを管理できることを説明する画像]

‍

従業員のアカウントが削除されたが、IAM経由でサーバーに接続されたケースはどういう意味ですか？SaaS 管理者は、単純なアカウント作成、割り当て、削除だけでなく、各従業員の SaaS 使用のライフサイクル全体を管理することで、SaaS の使用状況を可視化する必要があります。

‍

SaaS 管理プラットフォームの必要性

組織内でのSaaS管理の必要性を感じ、作成したプロセスがうまく機能しているかどうかを確認する必要がある。スプレッドシートでアカウントステータスを手動で更新することには、SaaS を多面的に可視化するうえで明らかな制限があります。各 SaaS で手動で管理されるアカウントが増えるほど、IT タスクにかかる負担、非効率性、およびセキュリティ上の脅威が大きくなります。

SaaSの利用が増え、IT環境がより複雑になるにつれて、プロセスを簡素化し、精度を高め、セキュリティを強化できるSaaS管理プラットフォーム（SMP）の必要性が高まっています。今こそ、組織に適した SMP を使用して、使用している SaaS リソースを最適化する時です。

‍

「POP」はアカウント管理を自動化することで退職手続きの安全性を高めます

PoPs（POP）は、シングルサインオン（SSO）と二要素認証に基づくSaaS管理プラットフォームです。ユーザープロビジョニングにより、採用に必要な SaaS アカウントが自動的に追加され、退職したアカウントは自動的に削除されます。組織で使用されている SaaS は 1 か所で管理され、権限の割り当てと取得が簡単になるため、IT スタッフは時間を節約でき、より重要なタスクに集中できます。SaaS 全体のコストと使用状況が一目でわかり、効果的な SaaS 運用管理が可能になります。

POPsについてご不明な点がございましたら、お気軽にお問い合わせください。👉 POPsに問い合わせる