0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

認証、認可について

Last updated at Posted at 2025-04-25

■本記事の目的

クラウドサービスやデータプラットフォーム、BI分析ツールなどを
色々取り扱ってきましたが、その中で掲題の件について
整理してまとめていきたいと思います。

■なぜ、この記事を書くのか

筆者の勤め先が、データ分析基盤やAIアプリを取り扱っているのですが、
この認証周りについて、
製品・プラットフォームごとで、質問を多く受けることが多かったため、
基本的なことをまとめてみようと思いました。

確かに考えてみると
製品・プラットフォームによって、認証周りのID・事柄・概念・呼び方は
異なるので、混乱するのかもしれません。

■認証とは

認証とは何なのかですが、本人確認です。
英語だと「Authentication」、その略語で「AuthN」とか言ったりします。

この本人とは、
一般的には自分自身のユーザーのことを示す場合が多いですが、
システムを取り扱っているとそうはいきません。

以下のように本人の定義や呼び方が色々あったりします。
一般的なユーザーのほかにも、システム間接続やAPIなど、本人確認の目的は様々です。
〇ユーザー:
 ・エンドユーザー:単にユーザーと言っているのは概ねこれ
 ・システムユーザー
 ・サービスユーザー
〇プリンシパル:
 ・ユーザープリンシパル
 ・サービスプリンシパル
〇ID(Identity):
 ・ユーザーID
 ・マネージドID
〇特殊:
 ・ロール(AWSのみ)

 
本人確認のためには照合する何かが必要になりますが、
「パスワード」が用語として広く一般かと思います。
簡単に言うと「鍵(キー)」が分かりやすい言葉ではあります。
こちらも呼び方が色々あります。
〇鍵関連用語:
 ・パスワード
 ・トークン
 ・シークレット
 ・鍵(キー)
 ・証明書
 ・署名

 
システム、デバイス、アプリに詳しい方だと認証という言葉を、
以下のような関連で見たことはあると思います。
〇認証関連用語:
 ・ユーザー/パスワード認証
 ・多要素認証
 ・二段階認証
 ・SAML認証(Security Assertion Markup Language)
 ・キーペア認証
 ・フェデレーション認証
 ・OAuth ※厳密には認可の仕組み
 ・ワンタイムパスワード認証
 ・生体認証
 ・PIN(Personal Identification Number)

 
ここまで整理しましたが、本人確認と一つの用語を取っても、
種類と戦略が、いくつかあることが分かります。

システムごとでの認証を検討する際は、顧客要件に応じて製品仕様を調査して、
認証方式を選んで構成する必要があります。

 
システムで認証を構成する際に意識しておくことがあります。
それは「本人情報および鍵の所在」です。

シンプルですが、これを意識するだけで、ほとんどの認証システムを理解できます。

認証プロセス(一旦認可は除く)と言うのは、ユーザー確認、照合を行うわけですので、
どこのユーザーが、どこの鍵を使用して、○○に認証する」ということを
抽象的に理解しておきます。

認証の苦手意識を持ちやすい原因になりやすい、
SAML認証におけるIdP(IDプロバイダー)、鍵管理サービスが出てきても、
上記の理解があれば簡単になると思います。
※実際のレスポンスは、もう少し複雑ですが、最初は抽象理解ができればいいです。

■認可(承認)とは

次に、認証をクリアした後、
ユーザーに対して何ができるかを決める必要があります。
それが認可となります。製品・サービスによって承認とも言います。
英語だと「Authorization」、その略語で「AuthZ」とか言ったりします。

認可を決定する定義として以下の用語があります。
※サービス・製品によって概念は異なります。
 ・権限
 ・パーミッション(単純に英語です)
 ・ポリシー
 ・ロール

このあたりは、各製品ごとに依存する部分となります。
細かいアクセス権限のグループ化や権限制御レベルを管理階層で行うなど
各仕様は異なってきます。

■グループ

認証、認可に関わる部分としては、グループがあります。
これについても認可と同様に製品依存になりますが、
認可を効率的に付与するためのユーザー管理と考えれば良いです。

認証、認可の管理のベストプラクティスとして、
グループがあれば使用する方が良いでしょう。

■その他

SAML認証で特定のIdP(IDプロバイダー)を利用すると、
条件付きアクセスなどで本人属性を含めて
認証を構成することができます。
※IdPがサポートしている機能によります。
 例えば、MicrosoftEntraIDであれば、
 アクセス元のデバイス、IPアドレスなどを属性として
 認証の際に照合できます。

 
最後に、
簡単な記事になりましたが、どの認証でもこの基本を押さえれば、
大きくは変わらないので使えると思います。
振り返ると、認可部分の制御が製品固有で、
一番インプットの負荷が高いのかもしれません。

参考:
https://solution.kamome-e.com/blog/archive/blog-security-20211021/
https://sciencepark.co.jp/information_security/post/approval/

 
どこかで、SAMLとIdP(IDプロバイダー)についてまとめたいと思います。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?