.png){kind=small}
Vol.08 ID・パスワードだけで大丈夫？認証・認可の基礎知識
- mitsuruto32
- 4月15日
- 読了時間: 14分
この記事であなたがやるべきこと
認証/認可の違いを理解する。ざっくりいうと以下の通り。
認証：あなたは誰？
認可：あなたは何ができる人？
パスワードオンリーは極力避け、生体情報や所有情報を活用した「パスワードレス認証」を取り入れる
出来る限り認証は恒久的ではなく、時間制限付きの「ジャストインタイム・アクセス」の考え方で
アプリケーション/サービス個別で認証情報を作らせず、SAMLやOAuthで効率よく認証/認可を行う
認可の設計するときは、まずRBAC/ABACをベースに検討する
認証/認可のポイント、押さえている自信ありますか？
セキュリティを学ぶうえで超基礎的な概念として、「認証/認可」があります。でも、プログラムやサーバを動かす仕組みとは直結しないですし、IT業界以外であまり使わない用語なので、特にエンジニアになりたての初心者には結構とっつきにくいですよね。
でも、認証/認可はアプリケーション、インフラのどちらを担当するとしても避けて通れない必須知識です。認証/認可について理解が浅いと、
「この人、自分が使っているシステムの認証/認可のことも全然わかってなさそうだな」、と不安に思われる
脆弱な設定や設定ミスによって不正アクセスされ、ニュース級のセキュリティ事故を引き起こしてしまう
ということが起こりえます。そうならないためにも、初心者だからこそ、早めに認証/認可において知っておくべきところ、やっておくべきことは網羅しておきたいところです。
そこで、今回はなるべくわかりやすく認証/認可の違いと仕組みを説明し、最新の動向を踏まえて押さえておくべき認証/認可の基礎知識をお伝えしたいと思います。
そもそも認証/認可とは
認証と認可って、言葉からして似ている感じがして、最初は違いを覚えづらいですよね。ご存じの方もいるかもしれませんが、改めて言葉の定義を確認します。
先にざっくり結論から言うと、
認証：あなたは誰？→私は●●です
認可：あなたは何ができる人？→私は■■を操作できる人です
という違いでイメージしてください。
認証：あなたは誰？
認証（Authentication）は、システムやサービスが「そのユーザーが間違いなく本人であるか」を確認するプロセスです。例えば、ログイン画面でIDとパスワードを入力するのは典型的な認証の例です。
認証に使う要素としては、知識情報、生体情報、所持情報などがあります。
知識情報
ユーザーが知っている情報を利用する認証方法です。最も身近な例は「パスワード認証」です。
生体情報
ユーザーの身体情報を利用する認証方法です。指紋認証や顔認証、虹彩認証などが該当します。
所持情報
ユーザーが所持している物理的なアイテムを利用する認証方法です。スマートフォンのSMSや認証アプリによるワンタイムパスワード（OTP）、ICカード式入館証などが該当します。
認可：あなたは何ができる人？
認証が成功すれば、そのユーザーが「誰であるか」が確認され、場所や情報へのアクセスが許可されます。ただし、それだけでは困るケースがあります。
例えば、とある学校に警備員がいました。休日の朝に学校に入ってこようとする人に身分証明書の提示をお願いしたところ、学生証を見せてくれたので、学校には入れてよさそうです。しかしその後、警備員は学生から
「部室の鍵が欲しいんですが、鍵は職員室にあるので、職員室の鍵を貸してください」
と言われました。しかし、警備員は、学生に職員室の鍵を貸して良いものなのかがわからず、困惑してしまいます。
つまり認証だけしても、「その人に何をする権限があるか」がわからない、あるいは定義されてないと、正しくセキュリティを守ることが出来ません。
それを制御するのが「認可」です。
認可（Authorization）は、認証されたユーザーに「どのような操作を許可するか」を制御するプロセスです。例えば、同じシステムにログインしても、一般ユーザーと管理者では利用できる機能が異なることがあります。
認可はそこら中で使っている概念ですが、エンジニアに身近な例は以下のあたりでしょうか。
クラウドストレージ
一般ユーザーは自分のファイルしか編集できないが、管理者はすべてのファイルにアクセスできる
Git
AチームはPushまで実施できるが、BチームはPullまでしか実施できない
OS操作権限
Linuxにおいて、rootユーザはネットワーク関連の設定変更ができるが、アプリ開発者用ユーザは設定の参照すらできない
以上が認証/認可の定義になります。もし細かい定義や具体例まで覚えきれなくても、
認証：あなたは誰？
認可：あなたは何ができる人？
だけ覚えておけば、あとは使っていく中で整理できていくでしょう。
認証/認可の基礎知識として押さえておくべきこと
ここからは、認証/認可について特に押さえておくべき基礎知識を、近年のトレンドも踏まえて解説します。基本的に技術的な仕組みは抜きにして、考え方や概念を中心に話していきます。
パスワードは流出するもの。時代は「パスワードレス認証」
認証方法のもっとも代表的な例であるパスワードですが、近年はパスワードに頼らない「パスワードレス認証」が当たり前になってきています。
様々なWebサイトやアプリでユーザー登録が求められる中、自分が利用しているサービスでパスワードが流出することはもはや珍しくありません。（直近でもハンズのアプリで12万人のパスワード情報を含む個人情報の流出がニュースになっていましたね）
今の時代は「パスワードはいずれ流出するもの」と認識しておき、使いまわしを避けるのはもちろん、そもそもパスワードだけに頼らない認証をしようね、という流れになっています。
パスワードレス認証では、先ほど認証の章で説明した3つの情報のうち、「所有情報」や「生体情報」を利用します。具体的には以下のようなものを使います。
指紋/顔認証
OTP（One-Time Password） ※メール、SMS、デバイス等の所有を確認
FIDO認証
場合によっては、従来のパスワードにプラスアルファで上記のような認証を組み合わせて使います。例えばユーザIDとパスワードを入力した後、スマホのSMSや登録したメールアドレスに6桁の数字が送信されて、その入力を促されるタイプのものがそうです。複数の認証方式を組み合わせるので、2要素認証（2FA）とか多要素認証（MFA）とも呼ばれます。
特にOTPはライブラリやプラグインとして誰もが実装しやすい形になっていることも多いので、システム設計/実装時に「OTPが簡単に使えないかな～」というのを都度都度気にしてみると良いです。例えば以下のようなものがあります。
Better Auth
様々なWebアプリケーションやAPIで利用可能な、認証システムを提供するライブラリ。SMSや認証アプリ（Google Authenticator等）を利用した認証が手軽に実装できます。
WordPressの2要素認証プラグイン
ブログやWebサイト構築で広く利用されるCMSのWordPressでは、管理画面へのログインに2FAを実装するプラグインが簡単に利用できます。
認証は恒久的ではなく一時的に。「ジャストインタイム・アクセス」
認証情報やセッション情報、付与する権限に時間制限をつけるという考え方も最近はスタンダードになってきています。これは、ユーザーに対して必要な権限を1時間、1日だけといった有効期限付きで付与する方式です。「ジャストインタイム・アクセス」とも呼ばれます。
これの何がいいかというと、認証情報が盗まれたときのリスクを下げられることです。例えば、何かの拍子に認証情報を外からアクセスできる場所にアップロードしてしまい、攻撃者に盗まれたとしても、その認証情報の有効期限が切れていれば使い物になりません。
ジャストインタイム・アクセスの具体例として、以下のようなものが挙げられます。
Microsoft Entra ID Privileged Identity Management
MicrosoftのEntra ID（旧Azure AD）において、必要なタイミングだけロールを利用できるようにする機能です。管理ロールの割り当てをあらかじめ決められた時間しか行えないように制限する機能を持っています。
AWSの一時的な認証情報発行
AWSにおいても、一時的な認証情報はよく活用されています。Identity Centerから払い出されるAWS CLI用の一時アクセスキーや、AWS STS（Security Token Service）の有効期限付きassume-role等が該当します。
JWT（JSON Web Token）
JWTとは、JSON形式でフォーマットされた情報をURL文字列などに入れて安全に送受信できるようにするための標準規格で、アプリケーションの認証や情報の安全なやり取りに利用されます。アクセスを短時間だけ有効にしたい場合によく使われています。
認証/認可を行うときには「これ、時間制限つけられるかな？つけなくてもいいかな？？」と気にする癖をつけて、適切なタイミングでジャストインタイム・アクセスを取り込めると、「お、セキュアじゃ～ん！イケてるじゃ～ん！」と思ってもらえることが増えるかもしれません。
それと同じ以上に、「しょっちゅう認証切れて不便なんだよ」って言われることもあるかもしれません。
認証・認可は面倒だから基本減らしたいけど、セキュリティは保ちたい。それを実現したのが「SAML、OAuth」
今の時代、認証・認可無しでのシステム利用はできない、というのは共通認識だと思います。でも、日常的にたくさんのアプリケーションやサービスを行き来する中で、それぞれの認証情報を管理しておき、毎回認証を求められるのは嫌気が指しますよね。私はこの話をするときいつも、楽●銀行と●天カードやらの楽●なんとかシリーズのパスワードがどれがどれだかわけわからなくなって発狂したことを思い出します。（今は反省してちゃんと管理しています）
そうしたことを解決するために「認証は1か所で管理して、1回ログインしたら全サービス使えるようにしよう」という考え方が生まれました。これがシングルサインオン（SSO：Single Sign On）です。認証を一括管理するSSOサーバーで認証を受けたら、その認証情報で複数のシステム/サービスが利用可能になる、という仕組みです。
SSOの有名な仕組みとして、SAML（Security Assertion Markup Language）認証があります。
SAMLにおいては認証を管理するサービスをIdP（Identity Provider）と呼び、その認証情報を使ってログインする先となるサービスをSP（サービスプロバイダ）と呼びます。例えばMicrosoft 365のアカウントを使って別アプリケーション/サービスにログインできるようにする、といった使い方ができます。SAMLは現在かなり多種多様なサービスで利用可能になっています。
似たような概念にOAuthというものがあります。
OAuthはざっくり言うと「複数のサービスを利用するときに、いちいちID・パスワード入力せずとも権限を渡す」ための仕組みです。これだけ聞くと「SAMLと同じ？」と感じそうですが、SAMLとの一番の違いは「認証情報を渡す必要がない」ということです。
認証情報を渡すと、悪用されたらなんでもかんでもできてしまうことになりますので、リスクを伴います。とはいえ、SSO的な利便性は欲しい...そんな時に生まれたのが、「認証情報は渡さず、一部の権限（認可）だけあげればいいじゃん」という考え方です。これを担うのがOAuthです。
OAuthの身近な例で言うと、とあるSNSとTwitterを連携して、とあるSNSで投稿すると自動でTwitter側にも投稿される、といったものがあります。
SAMLとOAuthの仕組みを詳しく説明するとそれだけで1記事になってしまうのでこの場では割愛しますが、興味を持った方はぜひ調べてみてください。
ここでは、システムに認証/認可が必要になったとき、「これ、SAMLかOAuthで楽できるんじゃないの？？」って発想に必ず至れるように、まずは概念としてしっかり覚えておいてください。
認可の代表的なモデル、「RBAC/ABAC」
認可について押さえておくべき基礎知識として、RBACとABACがあります。これらも認証/認可を学習する際には当たり前のように出てきますし、最近の技術の認可のモデルはだいたいどちらかに該当することが多いので、しっかり理解しておきましょう。
RBAC（Role-Based Access Control）
ユーザーの役割（Role）に応じて権限を与える方式です。例えば組織内の役職によって権限を分けるケースです。メンバーは自分の評価表だけ参照できるが、部長は部門の全メンバーの評価表を確認できる、という使い方はRBACに該当します。
ABAC（Attribute-Based Access Control）
ユーザーの属性（Attribute）に応じて権限を与える方式です。属性の例としては、ユーザーの所属部門や場所、アクセスされた時間などがあり、これに応じてアクセスの許可/拒否を判断します。国外からのアクセスだけ拒否する、平日日中帯のみアクセスを許可する、という使い方がABACに該当します。
RBACは比較的わかりやすくシンプルに実装できるものの、複雑でセンシティブなアクセス制御はできないというメリット/デメリットがあります。一方で、ABACは動的できめ細やかなアクセス制御要件に対応できるものの、実装がRBACに比べて難しいという特徴を持ちます。
初めてアクセス権限付与を設計することになった場合、まずはRBAC/ABACをベースに考え始めてみると、初心者からでもそれなりのレベルに持っていきやすいです。その際、RBACとABACの長所/短所とユースケースをしっかり理解したうえで判断できるように理解しておきましょう。
よくある質問
Q.1 認証/認可って本当にそんなに重要？大げさじゃない？
「なんだ、認証/認可なんていつも当たり前に触れていることじゃん」
「定義だけ知っておけば、あとは難しいことないんじゃないの？」
と思った方もいるかもしれません。
だからこそ危険なんです。ログインしたり、権限を付与したりというのはシステムを扱う中であまりに日常的に行うため、油断しやすいです。そのくせ、案外簡単に脆弱性を生みます。
例えば、
運用の中で頻繁にログイン操作を行うので、いちいち資料を見なくても入力できるように、パスワードは全員が暗記しやすい「P@ssw0rd」を使う
アプリの動作確認のたびにインフラ担当者にサービス起動をお願いするのが運用上大変なので、アプリ担当者にも強めの権限を付与してしまう
ソースコードに認証情報を埋め込んだままGitにアップロードしてしまう
など、割とありがちな話です。
しかし、油断や脆弱な設定が原因で大規模なセキュリティ事故につながったケースはいくつもあります。Gitに認証情報をアップロードしてしまったために29万件以上のお客様メールアドレス等を流出してしまったトヨタコネクティッド株式会社の事例や、MFAを行っていなかったが故に、パスワードリスト攻撃で46万件の個人情報が流出したユニクロ、GUの事例など、Web上で公開されているものだけでも挙げきれないほど見つかります。
ニュースになるようなランサムウェア攻撃や情報漏洩は、認証情報を盗まれて不正アクセスされたことがきっかけとなっているものもたくさんあります。しかし、セキュリティと運用効率性は基本的にトレードオフなので、慣れれば慣れるほど運用効率性に倒れがちです。上記のようなリスクがあることをちゃんと認識して、押さえるべきポイントは理解して、対策を実践しておきましょう。
Q.2 認証/認可の仕組みって、すでに実装されているライブラリやAPIを使うので、細かいことは知らなくても良くない？
一理あります。認証/認可に限らず、IT業界は技術の進化が異常に早いので、「前はイチから作ってたものが、誰でもつかえるような形（ライブラリ、プラグイン、サービス等）になりました！」というのはよくあります。
そういったものを、ゼロから作れるように学習しておくことは必須なのか？と言われると、仕組みを知らなくても使えちゃってなんとかなるケースも多いのは事実です。
ただし、冒頭でも述べた通り、認証/認可はＩＴに携わるエンジニアなら日常的に触れるので、わかっていないことで
お客さんからの認証/認可周りの質問に答えられず、不安感や不信感を与える
エンジニア同士の会話で認証/認可の話題についていけず、ナメられる
何を使って認証しているのかわからず、実装時や障害時の原因調査に時間がかかる
ということになる可能性はあります。
時間を割きすぎないようにしつつ、こういうことを避けるためにも、「ゼロから作れるほどわからないけど、大体の概念はわかるし簡単に説明できる」ぐらいにはなっておいた方が無難です。
まとめ
今回は認証/認可の違いと基礎知識について簡単に説明しました。技術的な仕組みまで理解が及ばなくても、まずは
パスワードオンリーは極力避け、生体情報や所有情報を活用した「パスワードレス認証」を取り入れる
出来る限り認証は恒久的ではなく、時間制限付きの「ジャストインタイム・アクセス」の考え方で
アプリケーション/サービス個別で認証情報を作らせず、SAMLやOAuthで効率よく認証/認可を行う
認可の設計するときは、まずRBAC/ABACをベースに検討する
これらを必要な時に必ず思い出して実践できるだけでも第一歩としては十二分でしょう！
実を言うと、筆者自身もエンジニアになりたての頃は「認証/認可」という言葉だけで「つまらないし難しい」という苦手意識を持っていました。インフラ領域を担当していたので、認証/認可の知識の重要性は分かっていましたが、資格試験や実務で何度か学んでも、右から左に抜けていってしまう毎日...。
今回は、そんな当時の自分に教えに行くような気持ちで、できるだけシンプルに解説したつもりです。認証/認可に苦手意識を持っている人ほど、理解が進む記事になっていたら嬉しいです。
