パスワードをなくせるなら、なぜ守る必要があるのか？

当たり前だと思い込んでいた問題

ほとんどすべてのウェブアプリケーションには管理画面があります。そして通常、管理画面にはログインページと認証フォーム、ユーザー名とパスワードがあります。

私たちはこの仕組みにすっかり慣れてしまい、すべてが本当にこのように動かなければならないのか、ほとんど考えなくなっています。

サイトが1つだけなら、大した問題には思えません。強力なパスワードを作り、二要素認証を有効にし、ログイン試行回数を制限すれば、それで作業できます。

では、プロジェクトが10、20、あるいは30に増えたらどうなるでしょうか？

私の場合、30を超える独立したソフトウェアプロジェクトで構成されるDigiMeldエコシステムが対象です。それぞれが独自のアーキテクチャ、サーバー側のロジック、管理インターフェースを持っています。

つまり、それぞれに管理者アクセスの仕組みが必要です。

長い間、私はごく一般的な方法を使っていました。管理者用の認証情報を個別に用意し、複雑なパスワードを設定して、ブラウザーに保存していたのです。

それで問題なく動いていました。

しかし、あるとき疑問に思いました。なぜ、これほど多くの管理者パスワードを保管しなければならないのだろう？サーバーだけでなく、そこへアクセスする手段まで守らなければならないのはなぜだろう？

そもそも、そうする必要をなくすことはできないのだろうか？

そして、やがて自分の解決策の土台となる考えにたどり着きました。

常設のログイン手段を守るのではなく、一時的にアクセスを得る権利そのものを守るべきなのかもしれない。

そもそも、いつものログインページがなかったら？

私は自分のプロジェクトで、従来型の管理者認証モデルをやめることにしました。

ログインフォームを隠すだけではありません。

アドレスを変更するだけでもありません。

パスワードを、さらに複雑なパスワードに置き換えるのでもありません。

常時存在するパスワードログインそのものを不要にするのです。

もちろん、管理インターフェースがなくなったわけではありません。アプリケーションを管理するには、今も欠かせないものです。

変わったのは、そこへアクセスする方法です。

現在、連携済みプロジェクトの管理画面にログインする際、保存済みのユーザー名とパスワードを入力する必要はありません。

その代わりに、私は独自の識別・アクセス管理システムであるMeldIDを使っています。

仕組みはとてもシンプルです。管理者アクセスは、本当に必要なときに、特定のユーザーに対して、特定のプロジェクトだけに付与されます。

アカウントが存在するというだけで、管理画面を開く権限が得られるわけではありません。

その権限は別途付与する必要があります。

1分前には存在しなかったアクセス

これはおそらく、このコンセプト全体のなかで最も興味深い部分です。

従来のモデルでは、管理者は常にログイン手段を持っています。その手段が有効な限り、今日でも、明日でも、1か月後でも使えます。

私はこの原則を変えることにしました。

常時有効な管理者認証情報の代わりに、ログインを開始するための一時的な手段を使います。

これは信頼済みのモバイル端末を通じてリクエストに応じて発行され、暗号学的に安全なランダム要素を含み、有効期間が限られています。

しかし、この一時リンクを持っているだけでアクセスできるわけではありません。

ここが重要なポイントです。

仮に誰かが何らかの方法でリンクを手に入れたとしましょう。アドレスの秘匿だけに頼る通常のシステムであれば、これは深刻な問題になり得ます。

私のモデルでは、リンクは確認手続きを開始できるだけです。

手続きを続けるには、信頼済みのMeldIDモバイル端末を使った別途の許可が必要です。

適切な確認がなければ、管理者セッションは作成されません。

だからこそ私は、一時リンクをパスワードの代替ではなく、アクセスを付与する手続きの一要素と捉えています。

アクセス先を知っていることと、ログインする権利があることは、まったく別の話です。

スマートフォンがアクセス管理の手段になる

このモデルでは、モバイル端末は一般的なワンタイムコード生成器よりもはるかに重要な役割を果たします。

管理者アクセスに関わる操作を確認するために使われます。

管理画面を開こうとすると、システムはMeldIDを通じた確認を求めます。

信頼済みの端末に該当するリクエストが表示されるので、操作を承認します。

確認が正常に完了して初めて、システムはログイン手続きを続行できるようにします。

この確認は、単にスマートフォンのロックを解除したという事実ではなく、特定の操作に紐づいています。

モバイル端末の生体認証でユーザーをローカルに確認し、サーバー側では登録済み端末からの暗号学的な確認を検証します。

この方法なら、パスワードだけに頼ったり、ユーザーがログインを確認したという申告だけを信頼したりせずに済みます。

さらに、信頼済み端末を管理できるという利点もあります。

ある端末をアクセス確認に使わなくなった場合、その端末の信頼ステータスを取り消せます。

その後、その端末は該当する操作の認証手段として使えなくなります。

1つのシステムで、独立した複数のプロジェクトを管理

この仕組みの開発を始めたとき、最も重要な課題の1つは、各プロジェクトの独立性を保つことでした。

すべての管理画面を1つの巨大なアプリケーションに統合したくはありませんでした。

DigiMeldの各サービスは、これまでどおり独自のロジック、設定、ユーザー、データを管理する必要があります。

そこで、2つの役割を分けました。

MeldIDは、識別と管理アクセスの付与を担当します。

一方、各プロジェクトは独自の管理機能と、現在有効な権限の確認を担当します。

こうして、アプリケーション自体を一元化することなく、アクセス管理を一元化できました。

また、権限は個別に付与されます。

あるプロジェクトの管理者がMeldIDアカウントを持っているからといって、他のプロジェクトにも自動的にアクセスできるわけではありません。

管理対象ごとに、アクセスを許可するユーザーの範囲を設定できます。

一般ユーザーの権限と管理者権限も、それぞれ独立しています。

数十のサービスからなるエコシステムでは、これは特に便利でした。

一時的なアクセスのほうが、常時アクセスよりも好ましい理由

このシステムに意識的に取り入れた原則が、もう1つあります。

管理者アクセスを無期限に維持してはいけない、ということです。

許可には有効期間があり、ユーザーがブラウザーで作業を続けているかどうかにかかわらず、その期間が過ぎれば終了します。

有効期間の終了後も作業を続けるには、あらためて確認手続きを行う必要があります。

これにより、一度認証しただけで権利が常に有効な状態になるのを防げます。

しかし、有効期間を設けるだけでは不十分です。

すでに付与したアクセスを、期限前に終了できることも重要です。

そのためMeldIDには、管理者権限を一元的に取り消す仕組みがあります。

許可が取り消されると、連携済みのプロジェクトにそのイベントが通知され、関連する管理者セッションが無効化されます。

つまり、アクセス管理はユーザーがログインに成功した時点で終わるわけではありません。

私にとって、権限を付与する機能と同じくらい、権限を取り消す機能も重要です。

一方、分散システムでは、イベントの伝達遅延、一部コンポーネントの一時的な利用不能など、運用上のさまざまな状況も考慮しなければなりません。セッションの有効期間を制限することは、もう1つの安全策になります。

日々の作業はどう変わったのか？

まず、保存済みの管理者パスワードを常に参照する必要がなくなりました。

連携済みの管理画面ごとに、ログイン用の認証情報をブラウザーに保存しておく必要はもうありません。

代わりに、単一の仕組みを通じて許可を管理しています。

必要なプロジェクトを選び、アクセスを確認して、作業します。

管理者アクセスが不要になったら、取り消すことができます。

新しいプロジェクトが加わっても、管理者認証システム全体を一から設計し直す必要がないのも、とても便利です。

既存のモデルに接続し、必要な許可を設定するだけです。

もちろん、これですべてのセキュリティリスクがなくなるわけではありません。

一時的な許可、信頼済み端末、サーバーセッション、中央インフラも保護する必要があります。

それでも、各アプリケーションごとに管理者パスワードを管理するという同じ課題に、何度も個別に対処する必要はなくなりました。

それこそ、当初の目標の1つでした。

こうした技術は、すでに存在するのでは？

もちろん、存在します。

パスワードレス認証、特権アクセス管理、一時的な許可、信頼済み端末による確認は、情報セキュリティの分野で以前から知られています。

こうしたアプローチは、Identity and Access Management、Privileged Access Management、Zero Trustの考え方を取り入れたシステムでも使われています。

私は、これらの原則を発明したと主張するつもりはありません。

私の目的は別のところにありました。

DigiMeldのインフラに固有の課題を解決し、独立した多数のプロジェクトに対する管理者アクセスを管理できる、独自の統合システムを作る必要があったのです。

その結果、いくつかの既知のアプローチを、自分の要件に合う1つのアーキテクチャにまとめました。

そして、エンジニアリングの価値は、まったく新しい技術を発明することだけにあるのではないと考えています。

問題を正しく定義し、それに合った解決策を見つけることに価値がある場合もあります。

MeldIDは管理画面だけのためのものではない

ここで、別途説明しておきたいことがあります。

MeldIDは、私自身の管理者アクセス専用のツールとして開発されたものではありません。

開発者向けのSDKも提供しており、独自のアプリケーションに識別やログイン確認の仕組みを統合できます。

しかも、このSDKは無料で利用できます。

たとえば、外部の開発者はMeldIDを、ユーザー認証における追加の確認レイヤーとして使えます。

アプリケーションで従来どおりユーザー名とパスワードによるログインを使い続ける場合でも、それらを正しく入力しただけでは認証を完了できないようにできます。

信頼済みのモバイル端末にリクエストが届き、ユーザーはそこでログイン試行を承認または拒否します。

これにより、認証情報が漏えいした場合の不正アクセスのリスクを下げられます。

MeldIDが広く提供しているこの機能と、私がDigiMeldのプロジェクト向けに構築した管理者アクセスのモデルは、区別することが重要です。

どちらも信頼と操作確認という共通の原則を使っていますが、解決しようとしている課題は異なります。

セキュリティとは、存在するものを守ることだけではない

このシステムに取り組むなかで、私は慣れ親しんだ認証の仕組みを別の角度から見るようになりました。

私たちは、歴史的な理由で存在している仕組みを守ろうとしがちです。

新たな確認手段や制限、追加のパスワード、防御レイヤーを加えていきます。

それが本当に必要な場合もあります。

しかし、ときには別の問いを立てるほうが有益です。

そもそも、守ろうとしている仕組みは、これまでと同じ形で存在し続ける必要があるのだろうか？

私の場合、答えは「いいえ」でした。

常時アクセス可能な管理者ログインフォームは必要ありませんでした。

必要だったのは、管理者権限を必要なときに安全に取得する方法です。

この2つは別の課題です。

前者から後者へと切り替えたことで、技術アーキテクチャだけでなく、プロジェクトに取り組む日々の業務も変わりました。

完成ではなく、選んだ方向性

現在、このアーキテクチャはDigiMeldエコシステムのかなりの部分で稼働しています。

残りのプロジェクトも、新しい管理者アクセスモデルへ順次移行しています。

各アプリケーションの動作を確認しながら段階的に移行を進め、移行が完了した後にはシステム全体の追加監査を行う予定です。

インターフェースの一部やセッション管理のルールは、今後変更される可能性があります。

しかし、基本となる考え方はすでに定まっています。

自分の数十のプロジェクトを管理するために、何十もの管理者パスワードを常に保存し、使い続けなければならないモデルに戻るつもりはありません。

一方で、自分の実装が誰にとっても万能な解決策だとは考えていません。

組織ごとに、要件もインフラも脅威モデルも管理方法も異なります。

DigiMeldのエコシステムで便利かつ妥当な方法が、別の開発者にとって最適とは限りません。

それでも、権限を一時的に付与するという原則には注目する価値があります。

おわりに

私がこの経験を共有しようと思ったのは、新しい認証方法を発明したと考えているからではありません。

また、別のシステムを絶対に安全なものとして紹介したいからでもありません。

絶対的な安全性は存在しません。

ただ、この問いの立て方そのものが興味深いと思うのです。

常設の管理者ログインを延々と保護する代わりに、それが存在し続ける必要があるのかを見直すことができます。

多数のパスワードを保存する代わりに、一時的な許可を使う。

最初の認証後に自動的に信頼する代わりに、具体的な権限の付与を確認する。

セッションの終了を待つ代わりに、アクセスを一元的に取り消せるようにする。

そして最後に、プロジェクトごとに個別のログイン機構を用意する代わりに、アプリケーションの独立性を保ちながら、管理アクセスを一元管理するシステムを構築する。

このアプローチによって、侵害の可能性がなくなるとは主張しません。

常に存在する認証情報を守ることから、権限を管理された形で付与し、終了させることへと、重点を移すだけです。

攻撃対象領域を減らす最も効果的な方法は、追加の防御策を重ねることではなく、なくてもシステムが十分に機能する仕組みを手放すことなのかもしれません。

私にとって、MeldID Admin Gatewayの物語は、まさにこの考えから始まりました。