IT設定ドリフト（Configuration Drift）とは

IT設定ドリフト（Configuration Drift）とは、システムやアプリケーションの設定が、当初の意図した状態（ベースライン）から時間とともに少しずつずれていく現象です。「構成ドリフト」「設定ずれ」とも呼ばれます。

個々の変更は小さく、そのほとんどが意図的に行われたものです。しかし積み重なることで、セキュリティポリシーやコンプライアンス基準から気づかないうちに大きく外れてしまいます。SaaS・クラウドの利用が当たり前になった今、管理対象のシステム数が増えた分だけドリフトは発生しやすくなっています。

「最初に正しく設定した」という認識のままシステムを運用し続けると、脆弱な状態が知らず知らずのうちに積み上がります。これが設定ドリフトの本質的な危険性です。

なぜ今、IT設定ドリフトが注目されているのか

SaaS・クラウド利用の急拡大が引き金に

企業が利用するSaaSアプリケーションは年々増加しています。利用するSaaSが100を超える企業も珍しくなく、管理対象が増えるほど各システムの設定状態を正確に把握し続けることは難しくなります。

クラウドネイティブ環境では、インフラの変更がコードベースで頻繁に行われます。担当者が変わったり手動で変更が加えられたりすることで、ベースラインからの乖離が気づかないうちに広がっていきます。

クラウド・SaaSの設定ミスが侵害の主因に

IBMをはじめ複数のセキュリティレポートが、クラウドにおけるセキュリティインシデントの主要因として「設定ミス（Misconfiguration）」を挙げています。設定ドリフトは、その設定ミスを生み出す根本的なメカニズムのひとつです。

IT設定ドリフトが発生する主な原因

設定ドリフトは特定の誰かの悪意ではなく、日常的なIT運用の中で自然発生します。

1. 記録されない手動変更

最も多い原因が、変更管理プロセスを経ない手動の設定変更です。

障害対応の際に一時的にファイアウォールルールを緩和し、そのまま戻し忘れるケース。ベンダーサポートのためにMFA（多要素認証）を一時的に無効化し、再有効化が漏れるケース。いずれも担当者の善意や緊急対応の産物ですが、ドキュメントに残らなければ「設定がずれた」という事実自体が見えなくなります。

変更管理台帳が整備されていても、緊急時の対応や個人判断で行われた変更がすり抜けるケースは現場で絶えません。

2. ソフトウェアアップデートによる設定リセット

SaaSベンダーやOSのアップデートが、既存の設定を書き換えてしまうことがあります。

新機能リリースに伴ってデフォルト設定が変更される場合や、パッチ適用後に明示的にオフにしていたオプションが再度オンになるケースが報告されています。SaaSプロバイダー側のプラットフォーム更新により、準拠していた設定が非準拠に転じることも実際に起きています。

アップデートのたびに全設定を確認するのは現実的ではなく、これが設定ドリフトの温床になります。

3. チーム・担当者間でのポリシー不統一

複数のチームや担当者がシステムを管理している場合、それぞれの設定方針が微妙に異なることがあります。

Aチームはパスワードポリシーを厳格に設定している一方、Bチームが新たに導入したサービスでは初期設定のまま運用されている、というケースです。担当者の交代や引き継ぎが不完全な場合も、設定の意図が伝わらずにドリフトが進みます。

シャドーIT（IT部門が把握していない部門導入のSaaS）が横行する環境では、管理外のシステムの設定状態を追いようがないため、ドリフトリスクはさらに高まります。

4. クラウド・ハイブリッド環境の複雑性

オンプレミスとクラウド、複数のSaaSが混在するハイブリッド環境では、設定管理の複雑性が格段に増します。

クラウドリソースは自動スケーリングや動的プロビジョニングにより、インスタンスが頻繁に増減します。新しいインスタンスが立ち上がるたびに既存の設定ポリシーが正確に引き継がれるとは限らず、環境間の差異が少しずつ広がっていきます。マルチクラウド環境では各プロバイダーの設定項目が異なるため、統一的な管理はさらに困難です。

5. 権限の付与しっぱなし問題

プロジェクト単位やトラブルシューティング目的で一時的に付与された昇格権限が、終了後も放置されるケースも典型的なドリフトの一形態です。

OAuth連携の許可スコープが気づかないうちに拡大していたり、退職者のアカウントが削除されずに残っていたりすることも、広義の設定ドリフトとして捉えられます。

IT設定ドリフトがもたらすリスク

放置すればするほど、リスクは複合的に拡大します。

セキュリティ脆弱性の増大

設定ドリフトが最も深刻な影響を与えるのがセキュリティです。

ファイアウォールルールが意図せず緩和されていれば、攻撃者の侵入経路が生まれます。SSH（ポート22）やRDP（ポート3389）が想定外に開放されていれば、外部からの不正アクセスに直結します。TLS設定の変更によって通信の暗号化強度が下がれば、中間者攻撃（MITM攻撃）のリスクが高まります。

攻撃者はこうした設定の隙間を積極的に探索します。ドリフトが進んでいる環境は、意図せずして侵入に最適な状態を維持し続けることになります。

さらに、攻撃者が侵入後にメール転送ルールやクロステナントアクセス設定を変更し、長期的な潜伏状態を作り出すケースも報告されています。設定変更自体が攻撃手法として使われる点も見過ごせません。

コンプライアンス違反・監査リスク

PCI DSS、ISO 27001、SOC 2、個人情報保護法対応など、多くの企業はシステム設定が一定の基準を満たしていることを継続的に証明する義務があります。

設定ドリフトによって、準拠していたはずの設定がいつの間にか基準を外れていた場合、監査での指摘にとどまらず、制裁金や業務停止のリスクにつながります。設定が常に正しい状態にあることを証明できないこと自体が、コンプライアンスの弱点になります。

システムパフォーマンスの低下

データベースの接続数上限が意図せず変更されていれば、高負荷時にパフォーマンスが急落します。リソース割り当ての設定が変わることで、クラウドコストが想定以上に膨らむこともあります。こうした問題は障害が発生して初めて気づくことが多く、原因調査に多大な時間を要します。

インシデント対応の遅延

設定ドリフトが進んだ環境では、インシデント発生時の調査が難しくなります。「本来どういう設定になっているべきか」が明確でないため、何が変わったのかを特定することから始めなければなりません。この遅延が、被害の拡大に直結します。

IT設定ドリフトの具体的な発生例

現場で起きやすい4つのパターンを整理します。

MFA無効化の放置 ベンダーサポートのためにMFAを一時的に無効化した管理者が、対応完了後に再有効化を失念。数週間後にそのアカウントが不正アクセスされるまで、誰も無効化に気づかなかった。

アップデートによるデフォルト設定の復元 クラウドサービスのメジャーアップデートにより、明示的にオフにしていたパブリックアクセス許可が再度オンになった。設定変更の通知を見落とし、数ヶ月にわたって外部からアクセス可能な状態が続いた。

退職者の権限放置 退職・異動のたびに適切なアカウント削除・権限変更が行われず、元従業員のアクセス権限が残存したまま。情報漏えいのリスクを抱えた状態が長期間続いていた。

SaaSのOAuth連携スコープ拡大 外部サービスとのOAuth連携が、SaaSの機能追加に伴いレビューなしにスコープを拡大。気づかないうちに不必要なデータへのアクセス権限が外部サービスに付与されていた。

ジョーシスは、SaaS・デバイス・アクセス権限を一元管理するプラットフォームです。設定ドリフトの検出から対策まで、どのように実現できるかを5分でわかる資料でご確認いただけます。 資料をダウンロードする（無料）

IT設定ドリフトの検出方法

設定ドリフトは「見えない変化の積み重ね」であるため、検出には仕組みが必要です。

継続的な設定監視（Continuous Monitoring）

設定の現在状態をリアルタイムで監視し、ベースラインと継続的に比較することが基本です。手動での定期チェックは現実的でないため、自動化ツールによる継続的なモニタリングが必要になります。設定の変化を検知した時点でアラートを発報する仕組みを整えることで、早期発見が可能になります。

ベースラインの文書化

検出の前提として、「あるべき設定状態」を定義・文書化しておくことが必要です。各システム・SaaSアプリの設定ベースラインを整理し、変更があった場合は変更管理プロセスを通じて記録します。ベースラインが明確でなければ、何がずれているのかを判定できません。

定期的な設定監査

四半期や半年に一度、主要なシステムの設定を一括でレビューし、ベースラインとの差異を確認するプロセスを設けます。継続監視と組み合わせることで、ドリフトの蓄積を二重に防ぎます。

バージョン管理・変更履歴の活用

Infrastructure as Code（IaC）アプローチでは、Gitなどのバージョン管理ツールで設定の変更履歴を追跡できます。「誰が・いつ・何を変えたか」を追跡できる状態を作ることが、ドリフト検出の基盤になります。

IT設定ドリフトの防止策

検出だけでなく、ドリフトが起きにくい仕組みを作ることが根本的な対策です。

変更管理プロセスの整備

すべての設定変更を変更管理プロセスに乗せることが、最も基本的な防止策です。緊急時の変更であっても事後に記録・承認するプロセスを設けることで、「記録されない変更」を最小化します。変更の影響範囲・理由・担当者を残すことで、後から追跡できる状態を維持します。

ロールベースアクセス制御（RBAC）の徹底

設定変更できる権限を必要最低限の担当者に限定します。最小権限の原則（Least Privilege Principle）に基づき、誰でも設定変更できる状態を避け、権限の定期的な棚卸しで不要な権限を回収します。一時的に付与した昇格権限は期限を設けて自動失効する仕組みが理想的です。

Infrastructure as Code（IaC）の活用

インフラの設定をコードで管理するIaCアプローチでは、設定が常にコードファイルに定義された状態に保たれます。TerraformやAWS CloudFormation、Ansibleなどのツールを活用することで、設定の一貫性を保ちながら変更履歴を追跡可能にします。コードレビューのプロセスに設定変更を組み込むことで、意図しない変更を事前にチェックできます。

SaaS設定管理プラットフォームの導入

複数のSaaSアプリケーションの設定状態を一元的に可視化し、ベースラインとの差異をリアルタイムで検知できるプラットフォームを活用することで、手動監査の限界を超えた管理が実現します。

ジョーシスのプラットフォームでは、350以上のSaaSアプリとの連携により、各アプリのアクセス権限・設定状態を一元管理し、設定の変化を可視化できます。情シス担当者が個別のSaaS管理画面を巡回することなく、一画面で設定ドリフトの兆候を把握できます。

定期的なアクセス権限レビュー

定期的にアクセス権限をレビューし、不要な権限・過剰な権限を回収するプロセスを制度化します。退職・異動時のアカウント処理を確実に行う仕組みと、OAuth連携の定期的な棚卸しも効果的です。

SaaS環境でのIT設定ドリフト対策：Josysの活用

SaaS管理において設定ドリフトへの対策を実践するうえで、ジョーシスのプラットフォームは複数の機能でサポートします。

SaaS Discovery：利用中のSaaSを可視化

管理されていないSaaS（シャドーIT）を検出し、企業内で使われているすべてのSaaSを可視化します。把握できていないSaaSは設定管理の対象外になるため、まず「使われているSaaSをすべて把握する」ことが設定ドリフト対策の出発点です。

Access Reviews：アクセス権限の定期棚卸し

ユーザーごと・SaaSごとのアクセス権限を一元的にレビューできます。誰がどのSaaSにどんな権限でアクセスできるかを定期的に確認し、過剰権限や不要権限を特定してコンプライアンス対応に役立てます。

Access Automation：入退社時の設定を自動化

入社・退社・異動のタイミングでのSaaSアカウント作成・削除・権限変更を自動化します。「手動で設定を変えたけど戻し忘れた」「退職者のアカウントが残っていた」というヒューマンエラーによるドリフトを、構造的に防止します。

Sales MarkerではJosys導入後にIT管理にかかる業務時間を約50%削減、MerryBizでは年間約600万円のコスト削減を実現しています。SaaS設定管理の効率化は、コスト削減とセキュリティリスク低減を同時に実現します。

ジョーシスのデモで、設定管理の一元化を体験できます。SaaS・デバイス・アクセス権限の設定状態を一画面で管理できるデモ環境をご用意しています。

‍デモを予約する

IT設定ドリフト対策のロードマップ

実際に対策を進める際の段階的なアプローチを整理します。

Phase 1：現状把握（1〜2週間）

まず、自社の設定管理の現状を確認します。管理対象となるシステム・SaaSの棚卸しと、各システムの現在の設定状態の記録から始めます。変更管理プロセスの有無と運用実態の確認、過去のインシデントで設定変更が関与したケースの洗い出しも有効です。

現状のギャップを可視化することが、優先度付けの基盤になります。

Phase 2：ベースラインの定義（2〜4週間）

次に、「あるべき設定状態」を各システムについて定義します。セキュリティポリシー・コンプライアンス要件に基づいたベースラインを策定し、ドキュメント化してバージョン管理します。変更管理プロセスを整備し、チーム内に浸透させることも並行して進めます。

ベースラインは一度定めたら終わりではなく、要件変更や新サービス追加に合わせて定期的に更新します。

Phase 3：継続的モニタリングの実装（1〜2ヶ月）

ベースラインが定まったら、継続的な監視の仕組みを導入します。設定監視ツールを導入し、自動検出・アラートの仕組みを整えます。SaaS管理プラットフォームと連携して複数のSaaSを一元管理し、アラートへの対応プロセスも合わせて設計します。

Phase 4：定期レビューと改善（継続）

四半期ごとの設定監査、アクセス権限の定期レビュー、検出されたドリフトの傾向分析と根本原因への対処を継続します。設定ドリフト対策は一度完了するものではなく、継続的な改善サイクルが前提です。

IT設定ドリフトに関するよくある質問

Q: 設定ドリフトはどのくらいの頻度で起きますか?

日常的なIT運用の中で恒常的に発生します。管理対象のシステム数が多いほど、また変更が多い環境ほど発生頻度は高まります。特にSaaSを多数利用している企業では、ベンダー側のアップデートだけでも設定変更が頻繁に起きるため、継続的なモニタリングなしには管理が困難です。

Q: オンプレミスとクラウドでは、設定ドリフトのリスクは違いますか?

どちらの環境でも発生しますが、クラウド・SaaS環境では特にリスクが高い傾向があります。クラウドはインスタンスの増減が動的で変更頻度も高く、さらにSaaS環境ではベンダー側の設定変更をこちらでコントロールできないという特有の問題があります。

Q: 設定ドリフトの検出に専門的なスキルは必要ですか?

専門スキルがあるほど精度の高い対策は可能ですが、SaaS管理プラットフォームや設定監視ツールを活用することで、専門スキルがない担当者でも自動的に設定ドリフトを検出できる環境を整えられます。ツールの活用が、スキルギャップを補う現実的なアプローチです。

Q: 設定ドリフトとシャドーITはどう違いますか?

シャドーITはIT部門が把握していないシステム・SaaSが利用されている状態、設定ドリフトは把握しているシステムの設定が意図した状態からずれていく現象です。ただしシャドーITが存在する環境では、管理外のシステムの設定が野放しになるため、設定ドリフトのリスクはさらに高まります。

まとめ

IT設定ドリフトとは、システムの設定がベースラインから少しずつずれていく現象です。SaaS・クラウドの普及により、現代の企業IT環境では特に深刻なリスクとなっています。

主な発生原因は「記録されない手動変更」「アップデートによる設定変更」「チーム間のポリシー不統一」「権限の付与しっぱなし」の4つです。放置すれば、セキュリティ脆弱性・コンプライアンス違反・システム障害につながります。

対策の柱は「ベースラインの定義」「継続的なモニタリング」「変更管理プロセスの整備」「最小権限の徹底」です。これらを継続的に実践するためには、SaaS管理プラットフォームの活用が実務上もっとも効率的なアプローチです。

設定ドリフトは、仕組みを整えることで「見えない変化」を「管理できる変化」に変えられます。まずは自社の設定管理の現状を把握することから始めてみてください。

ジョーシスで設定ドリフト対策を始める。350以上のSaaSとの連携で、設定状態の一元管理・アクセス権限の定期レビュー・入退社対応の自動化を実現します。5分でわかる資料でジョーシスの機能をご確認ください。

資料をダウンロードする（無料） ｜ デモを予約する

参考情報

参考情報：構成ドリフト：その概要、発生する理由と修正プログラム（IBM）

参考情報：Configuration Drift Explained（Wiz）

参考情報：What is Configuration Drift?（Nudge Security）

参考情報：Stop Risky SaaS Configuration Drift（Obsidian Security）