この記事では、認証と承認を安全に実行するためのシステムについて説明します。まず、認証と承認の違いを理解しましょう。
この記事では、次の内容について説明します。
会議中に、あなたが会話をリードしているとします。適切な相手に何かの更新や状況を尋ねるには、相手を識別 (つまり、認証) する必要があります。相手と機密データを共有する場合でも、相手を正しく認証する必要があります。ここで認証が重要になります。
さて、同じ会議でいくつかの決定を下す必要があるとします。そのため、それらの決定を下す権限を持つ人が決定を下すべきであり、全員にすべてを許可するわけにはいきません。明らかに、一部の人は決定を下すのに十分な配慮を受けておらず、最悪の事態を招こうとする人もいます。そこで、承認が必要になります。承認は、特定の人に特定のアクティビティの権限を与えます。
人物を認証するには、各人物に固有のフレーズを割り当て、その人物がそのフレーズと名前を正しく伝えれば、人物を識別できたと判断できます。これは、通常のユーザー名とパスワードのアプローチです。正しい資格情報が与えられると、システムは ID を有効とみなし、アクセスを許可します。これは 1FA またはシングル ファクタ認証(SFA) として知られています。
SFA はかなり安全ではないと考えられています。なぜでしょうか? ユーザーはログイン情報を安全に保つのが苦手だからです。多要素認証 (MFA) は、ユーザーが複数の方法で自分の身元を証明することを要求する、より安全な代替手段です。次のような方法があります。
一度認証されると、ユーザーはアプリケーション上で自由に操作を実行し続けることになります。そして、アプリケーションは、ユーザーが操作中ずっとユーザーを認識し、ユーザーを忘れないようにする必要があります。理想的には、ユーザーが別のページに移動するたび、または何らかの操作を行うたびにパスワードの入力を求めるのはやりすぎです。そのため、ユーザーが資格情報を入力して一度認証された後は、そのユーザーの認証を維持する方法が必要です。これをセッション管理と呼びます。
ユーザーの認証を維持する 2 つの方法:
これら 2 つのアプローチの主な違いは、トークンベースの認証はステートレスであり、トークンをサーバー側に保存する必要がないことです。ただし、セッションベースの認証の場合、トークンはサーバー側でも保存する必要があるため、ステートフルになります。そのため、システムが拡張されたり、ユーザー数が増えたりすると、複雑な問題が発生します。
トークンベースの認証では、主に JWT (JSON Web Token) を使用します。
ユーザーが認証された後も、アクセス許可のあるリソースにのみアクセスできるようにする必要があります。機密データへの不正アクセスは大惨事を招く可能性があります。最小権限の原則により、企業は通常、デフォルトで絶対に必要なものにアクセスできるようなアクセス ポリシーを設定します。そして、それに応じて追加のアクセスが与えられます。アクセスをセグメント化する一般的な方法は次のとおりです。
ACL は、ABAC や RBAC よりも細かいレベルで頻繁に使用されます。たとえば、個々のユーザーに特定のファイルへのアクセスを許可する場合などです。ABAC と RBAC は通常、会社全体のポリシーとして導入されます。
まず、システムの機能要件を定義することから始めましょう。
この記事の範囲では考慮しない非機能要件は次のとおりです。
トラフィック推定
まずトラフィックの見積もりから始めましょう。月間平均トラフィックを 100,000 と仮定します。月間 10 万ユーザー トラフィックを見積もります。これは 1 秒あたり 0.04 リクエストに相当します。各リクエストに対して 90% の時間で 500 ミリ秒以内に応答する必要があります。つまり、p90 レイテンシは 500 ミリ秒である必要があります。
assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04
サービス レベル目標 (SLO) : 500 ミリ秒 (システムの負荷に関係なく、許容可能な最大遅延) 特定のリクエストに対して負荷の高い処理が行われていないと仮定すると、1 つのインスタンスが要求を処理するのに要する平均容量は、当社の計算に基づいて約 35 ミリ秒です。
上記のメトリックを使用して、さらに 2 つの派生メトリックを生成してみましょう。
したがって、
SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04
需要と利用可能な容量に基づいて、必要なインスタンスの合計数を計算しましょう。
total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1
したがって、1 つのインスタンスで、1 秒あたり 0.04 リクエストで、毎月 10 万リクエストを簡単に処理できます。各ユニットは、SLO を損なうことなく、1 秒あたり 20 リクエストを処理できます。
ストレージの見積もり
理想的には、認証と承認アクセスのために各ユーザーのユーザー詳細を保存する必要があります。5kb /ユーザーと仮定します。
monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB
したがって、毎月 500 人の新規ユーザーをオンボードすると仮定すると、2 GB の追加ストレージが必要になります。認証ログを保持する必要がある場合、各認証リクエストの保存には 2 KB かかると予想されます。
auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB
したがって、月間トラフィックが 10 万であると仮定すると、毎月 200 MB の追加容量が必要になります。
容量の見積もりが完了したので、機能要件をサポートするために必要なデータベースのスキーマを作成しましょう。
テーブルを簡単に見ていきましょう。6 つのテーブルを使用します。
システムエンドポイント
終点 | 説明 |
---|---|
/ログイン | ユーザーの資格情報を認証します。 |
/ログアウト | ユーザー セッションを終了し、認証トークンを取り消します。 |
/登録する | 新しいユーザーを作成します。 |
/更新/:ユーザーID | ユーザー情報を更新します。 |
/削除/:ユーザーID | ユーザーアカウントを削除します。 |
/許可/:ユーザーID/:権限 | ユーザーに特定の権限を付与します。 |
/取り消し/:ユーザーID/:権限 | ユーザーの権限を取り消します。 |
/チェック/:ユーザーID/:リソース | 特定のリソースへのユーザーのアクセスを確認します。 |
/create/:ユーザーID | 新しいユーザー セッションを作成します。 |
/有効期限/:セッションID | ユーザーセッションを期限切れにします。 |
/検証/:セッションID | アクティブなユーザー セッションを検証します。 |
要件の充足
さて、すべての準備が整ったので、すべての要件をどのように満たすことができるかを見てみましょう。
登録
ログイン
セッション管理
パスワードの復元
アクセス制御
監査証跡
パフォーマンス
この記事では、まず認証と承認の違いについて理解しました。次に、認証および承認システムを作成しました。これは、安全で、セキュリティが確保され、業界標準に準拠し、必要な要件をすべて満たしながらパフォーマンスを発揮します。今後、この記事の特定の部分を更新して、関連性を維持し、このようなシステムの構築に関するより多くの情報と洞察を網羅する可能性があります。