TOUCH THE SECURITY Powered by Security Service G
パーソルクロステクノロジー セキュリティサービスGの金太郎です。プログラムが好きなインフラエンジニアです。今回、「認証基盤のニーズ」について数回に分けて説明します。私の失敗経験から、押さえておくポイントを伝えることができれば幸いです。
第一回目は、認証基盤導入における「目的」について説明します。次回以降は各ニーズの技術要素を伝えたれればと思っています。
まずは「目的？」いまさらって思うかもしれませんが、目的と手段が入れ替わることって良くありますよね。「常識だから」といった、思考や議論のショートカットによって、徐々にこれらがスワップ...心当たりありませんか。ということで、目的を明確にしながら顧客と議論することで、よりハッピーなエンジニア生活を広げていきましょう。
1.「認証基盤の導入」で何をイメージする？
認証基盤の目的について説明する前に、まず想像してみてください。例えば、あなたに上司から”セキュリティ強化”を目的とする「認証基盤導入プロジェクト」への参加依頼がありました。
ここで質問です。「認証基盤の導入」で何をイメージして、何を準備しますか。
いかがでしょう。例えば、ユーザやPCなどを管理する「Active Directory（以下AD）」をイメージして、「Windows以外のPCがある？」、「OU設計」、「グループポリシー設計」などに注目して準備するかもしれません。また、シングルサインオンを実装することを意識して、「OAuth2」、「Webサインオン」をイメージして人もいると思います。
意地悪な質問ですが、大手SIerやセキュリティエンジニアと一緒に仕事をしたとき、認証基盤イコール「AD」は多いです。
でも、なにか重要なことを忘れていませんか。そうです。上記は認証基盤の「手段」であり、認証基盤の「目的」ではありません。
2.認証基盤の目的
それではこの認証基盤の「目的」って何でしょう。定義できていますか。
私は認証基盤の目的を、「特定のアイデンティティを認可すること」と定義します。ちょっと分かりづらいでしょうか。では「アイデンティティ」について、「特定の属性（※）の集合体」と定義します。開発経験者ならクラス、構築経験者だとユーザアカウントをイメージすれば問題ないです。
※属性は「ユーザ名、姓、名など」
次は「認可」ですが、「保護されたリソースへのアクセスを許可すること」と定義しています。「保護された」も意識してください。保護されていないなら、そもそも許可する必要はないです。
大事なのでもう一度、認証基盤の目的を。「特定のアイデンティティを認可すること」です。
3.「認証基盤の導入」で何をイメージする？（もう一度）
では、敢えてここでまた、先ほどと同じ質問を。「認証基盤の導入」で、何をイメージして、何を準備しますか。
上記を踏まえ、これが私の思うベストな回答です。
「まずは、保護すべきリソースをイメージして、そして”アイデンティティ”と”認可”の関係を踏まえて下準備。（どの手段が一番良いかは、その後）。」
目的と手段の違い、わかりますか。
4.私の失敗談など
お客様から、セキュリティ強化を目的とした認証基盤の構築依頼がありました。環境は以下の通り。
- データはNASに保存しローカルアカウントで管理
- 社内の基幹システムは自社製のWebアプリのローカルアカウントで管理
- PCはローカルアカウントで管理
ここで、私はAD導入を提案しましたが却下されました（泣）。
なぜなら、自社製のWebアプリはクレームベース系でアイデンティティ管理が実施されていたからです。お客様のニーズは、（社内ネットワーク上では常識！の「ドメイン、統合認証」ではなく）「クレームベース系での統合」だったのです。イメージとして、社内ネットワークでひとつのインフラストラクチャではなく、社内ネットワーク内に複数のインフラストラクチャを配置して統合する感じですね。
もちろん、クレームベース系の認証については知っていましたし、構築したこともありました。ただ、手段について考慮にも入っていませんでした。常識だと思い熟考せず提案してしまったのです。
保護すべきリソースと運用コストを考慮した結果、クレームベース系である事には相応しい理由があったのです。エンジニアの方でも「AD未導入？セキュリティ的にダメですね」なんて会話をよく聞きますが、みなさん気をつけてくださいね。
ちなみに似たような事例と言いますか、私の関わっていたとあるゲーム会社で、インターネットからゲームデータ領域に対するファイアーウォール実装を取りやめた事があったんです。ここだけ抜き出してお話すると、ちょっと不安になりますよね？でもこれ、ファイアーウォール導入の目的を再検討し、保護すべきリソースと運用コストを考慮した結果、それが合理的だったのです。
ファイアーウォールとは、外部から保護すべきリソースを守るために導入するものです。そこで「外部からの攻撃」、「保護すべきリソース」を徹底的に分析しました。
結果、「外部からの攻撃」に対して、ファイアーウォールがそれほど効力を持たず、運用でカバーできていることがわかりました。また「保護すべきリソース」についても、ファイアーウォールを用いて保護すべき情報は少なく、分割管理が可能であることがわかりました。これは特殊なケースではありますが、常識とされる要素を、今一度皆で議論する事によって辿り着いた、解決策の一例です。
ということで、今回は認証基盤のニーズに対して、先ずは目的を明確にしながら顧客と議論する事の大切さに関するお話でした。
