ITエンジニアが語る、情シス部や経営者が知っておきたい「認証基盤の整備」とは

皆さん、こんにちは。

アイエスエフネット クラウドソリューション部の井口です。

前回、「テレワークと情報資産」と題しまして、テレワークにおけるセキュリティの重要性についてお話させていただきました。

（「テレワークと情報資産」はこちら：

https://www.isfnet.co.jp/isfnet_blog/index.php/2020/06/04/1664/ アイエスエフネットHP内）

その中で「IDと権限及び認可条件を整理すること」を推奨しましたが、引き続き、関連した、少々テクニカルな話をさせていただきます。

「IDと権限及び認可条件を整理すること」といっても、どこから手をつけていいか悩む方も多くいらっしゃると思います。

その最初のアプローチとして、今回お話しするのは認証基盤の構築になります。

とはいえ、さまざまなやり方があるので、気になる方はご相談くださいね。

認証基盤の構築・整備とは

現在の業務において、ほとんどの企業でITの利用は不可欠なものとなっています。さらに、利用だけを考慮すればよいという時代はとうに終わり、セキュリティも重視しなければなりません。

そのために必要なものが認証基盤の整備となります。

例えば、あるシステムを使用するにあたって、どのような方法をとるのか想像してみてください。

通常、まずは自分であることを示すIDとパスワードを入力しますね。

最近だと多要素認証なども必要不可欠になっていますが、とりあえずそれは置いておきましょう。（多要素認証の重要性については、別途お話ししたいと思います）

IDとパスワードでシステムにアクセスしたあと、全機能が使えるとかというと、人によって使える機能と使えない機能があると思います。例えば、管理職クラスであれば自分の部下の情報が閲覧できる、さまざまな申請に対して承認が使える、などです。

対して、一般社員はその機能が使えないようになっています。これは入力されたIDを基に、システムが使用可能の可否を判断しているからです。

IDとパスワードを入力してユーザーを識別することを「認証」といいます。認証されたユーザーに対して、システムがどこまで利用可能であるかを制御することを「認可」といいます。

もっと身近な日常での例を出してみましょう。

例えば、病院で診察を受けることを想像してみてください。

まず、受付で保険証を出すと思います。保険証は本人確認をするためのものですね。これがその人であることを証明する、つまり、保険証を持っていることで“本人であることを認証した’’ということです。

次に、ドクターに診察を受けると思います。ドクターは薬が必要か、さらに検査が必要か判断します。ドクターは患者に対して薬を使用してもよいか、検査をしてもよいか、という認可の判断しています。

保険証というどこでも使用可能な認証カードがあれば、日本中どこの病院でも身分が保証され保険適用で診察を受け付けてくれます。

これが、病院ごとに保険証が違ったらどうなると思いますか？歯医者の保険証、内科の保険証、耳鼻科の保険証などなど、大変なことになると想像できると思います。

話を戻すと、ITでも同様のことが言えます。

業務のIT化が当たり前になった現代では、さまざまなITシステムを業務で利用していると思います。業務システム、勤怠管理、経費精算、顧客管理、売上管理など。それらすべてが別々の認証システムで動いていたらどうでしょう。IDとパスワードをそれぞれ覚えなければならない、考えただけでうんざりすると思いませんか？

それぞれのシステム毎に認証を行っている場合、管理が煩雑となります。新規採用者の受入準備、退職者のアカウント削除といった定型業務であっても、それぞれのシステム毎に設定が必要になることを考えていただければ、管理の大変さが分かると思います。

管理が大変になれば、それだけミスが発生する可能性が高くなります。例えば、退職者のアカウントを消し忘れ、そのアカウントから情報が流出するなどといったセキュリティ事故が発生する可能性も考えられます。

管理面からもセキュリティ面からも認証を統合し、認証基盤として整備することが重要となるのです。

認証基盤の整備のために、やるべきこと

では、具体的に認証基盤の整備を行うにあたり、何をすればよいのでしょうか。

実はそれほど難しことではありません。まずは、「統一された一意のIDを確保すること」から始めてみましょう。

例えば、ActiveDirectoryのユーザーアカウントが一意という企業も多いでしょう。ADはWindowsに実装されて20年以上経つ技術です。Windows端末を業務端末として利用している多くの企業がAD使用していることでしょう。

また、メールアドレスが社員に一意に割り当てられている企業もあると思います。ドメインが変更にならない限り会社ドメインのメールアドレスは、社員に対して一意になるはずです。

さらに、人事データベースで管理している社員IDが、一意のIDという企業もあると思います。

これら一意のIDが決まれば、あとはそれを利用するシステムに対応した認証基盤サービスと連携するだけです。

昨今、ほとんどのシステムがクラウド前提で動いているため、クラウド上で稼働している認証基盤サービス（IDaaS）をお勧めします。

アイエスエフネットであれば、AD＋AzureADか、AD環境がなければAzureADからの認証基盤構築を推奨していますが、他にもOneLoginやOktaなども選択肢に入ってくるでしょう。どの認証基盤サービスを選択するかは、使用するクラウドサービスへの対応、認証基盤サービスの管理のしやすさなどを基準に考えるとよいと思います。場合によっては、一つに絞らずサービスによって２つのIDaaSを使い分けるという方法もあります。

詳しくは、アイエスエフネットの営業に、ぜひ聞いてみてください。

次回ですが、「IDと権限及び認可条件を整理すること」のIDを説明しましたので、残りの権限及び認可条件の整理についてお話ししたいと思います。認証が行われたあと、ユーザーにシステムをどこまで許可すべきなのか、その条件はどうすればよいか。このあたりのポイントについて説明します。

※この記事は、公開時点の情報をもとに作成しています。

関連ソリューション情報

Windows Server 2008のMicrosoft Azure移行支援ソリューション

Microsoft 365導入支援ソリューション

アイエスエフネット｜会社ブログ

まずは相談する方はこちら