ユーザー識別のための重要なセキュリティーチェックリスト
ユーザーの識別を構築することは、任意のアプリケーションの重要な要素です。ユーザー名とパスワードの確認は最も単純なアプローチのように見えるかもしれませんが、考慮すべき他の多くの側面があります。
Founder
序章
アプリケーションの重要な要素としてユーザー識別の構築は極めて重要です。これにより、パーソナライズされた体験を提供したり、データ品質を高めたり、ユーザーの保持を改善したりできます。
ユーザー名とパスワードの検証は最も単純なアプローチのように思えるかもしれませんが、考慮すべき他の多くの要素があります。始めましょう！
インフラ
HTTPS の強制
基本から始めましょう。常に HTTPS（Hypertext Transfer Protocol Secure）を使用して、インターネット上のデータ転送を暗号化します。HTTPS は、ユーザーのデバイスとあなたのサーバー間で交換されるデータが機密で改ざん防止されていることを保証します。
HTTPS の設定は難しそうに思えるかもしれませんが、これを支援する多くのツールとサービスが用意されています：
- 自己ホスティングの場合、Let's Encrypt はあなたのウェブサイトで HTTPS を有効化するために使用することができる無料の SSL/TLS 証明書を提供します。
- AWS、Azure、Google Cloud などのクラウドプロバイダーを使用している場合、HTTPS を設定するために彼らの管理サービスを使用できます。
パブリックデータベースへのアクセスを許可しない、信頼できるソースに限定
基本的なことのように思えるかもしれませんが、パブリックアクセスをデータベースに許可することによる数多くのセキュリティー侵害が発生しているため、ここで言及する価値があります。
常にあなたのデータベースへの公開アクセスを許可しないことを覚えておいてください。データベースをプライベートネットワークに配置し、信頼できるソースからのみアクセスを許可します。
私的トークンを安全に管理
アクセストークンや API キーなどのプライベートトークンは、プログラムの認証と認可の目的でよく使用されます。これらのトークンを安全に管理するには：
- 認証されていないアクセスのリスクを最小限に抑えるために、短期間のトークンと更新トークンを使用します。
- キーボールトなどの安全なトークンストレージメカニズムを使用して、トークンを不正アクセスから保護します。
- トークンが侵害されるのを防ぐために、定期的にトークンを交換します。OAuth 2.0 などの一部のプロトコルは、トークンの交換のメカニズムを提供します。
- セキュリティー違反の場合にトークンの取り消しをコントロールすることを確認します。
パスワードハッシュアルゴリズムを賢 く選択
パスワードハッシングの経験がある場合、MD5、SHA-1、SHA-2 など、安全でなくなったと考えられている多くのアルゴリズムがあることをご存知かもしれません。
その不安全性の一般的な理由は：
- パスワードのハッシングを目的として設計されていない、コンピュータの速度が速過ぎて、ブルートフォース攻撃が容易になる。
- ソルトの使用を欠くため、レインボーテーブルの作成が容易になる。
- 衝突攻撃に対して脆弱であり、攻撃者が同じハッシュ値を持つ異なるパスワードを生成することを許してしまう。
業界標準のパスワードハッシングアルゴリズム、bcrypt や Argon2 などは、これらの問題を解決するために設計されています。この記事の範囲が限られているため、それらについて詳しくは説明しません。詳細は パスワードハッシングの進化 を参照してください。
公開標準を学び厳格に遵守
OAuth 2.0 や OpenID Connect（OIDC）のようなオープンスタンダードは、ユーザーの認証と認可に対する安全で標準化されたアプローチを提供します。これらは業界で広く使用されており、バトルテストを受けています。
しかし、それらを誤って実装すると、経験豊富な 開発者を持つ大きなチームでもセキュリティーの脆弱性が生じることがあります。最近の例として、モバイルアプリのビルドに人気のあるフレームワークである Expo 内で発見された OAuth の脆弱性が挙げられます。これは、小さな誤りがどのようにセキュリティー侵害につながるかの良い例です。
データは休止状態で暗号化
ユーザー情報の格納やデータベースバックアップなどのデータは、強力な暗号化アルゴリズムを使用して暗号化するべきです。これにより、データが侵害されても、復号化キーがなければ読むことができなくなることが保証されます。準拠目的で一般的に必要とされるこの機能を、あなたのクラウドプロバイダーがサポートしているかどうかを再確認してください。
ファイアウォールを設定
DDoS（Distributed Denial of Service）攻撃は、古いにも関わらず、依然として大きな脅威です。2022年第4四半期の Cloudflare DDoS 脅威レポートによると、HTTP DDoS 攻撃トラフィックの量は前年比79％増加しました。自身のソリューションを構築するのではなく、管理されたファイアウォールを設定し、通知者を使用してこのリスクを軽減するのが良い考えです。
アプリケーションとクライアント
パブリッククライアントのセキュリティーレベルを改善
モバイルアプリやシングルページアプリケーションなどのパブリッククライアントは、セキュリティーの脆弱性にさらされやすいです。それらを提供していても、あなたのセキュリティーモデルではそれらを信頼されていないソースとして扱わなければならない。例えば：
- OAuth 2.0 を使用している場合、認証コードの傍受攻撃を防ぐために Proof Key for Code Exchange（PKCE）を使用します。
- Cross-Site Scripting（XSS）やデータインジェクション攻撃などある種の攻撃を軽減するために、Content Security Policy（CSP）を強制します。
パブリック入力データを決して信用しない
ユーザー入力は、よく見落とされるセキュリティーの脆弱性の重要なソースとなり得ます。一般的な種類の見落とされがちな脆弱性は、Cross-Site Scripting（XSS）や SQL Injection などです。それを使用する前に、すべてのユーザー入力データを検証しクリアします。
活動を追跡
ユーザー活動の監査トレイルを維持することは、セキュリティー事故の検出および調査に役立ちます。ログイン試行、パスワードの変更、機密操作などのユーザー行為をログに記録し監視します。これらのログを分析することで、潜在的なセキュリティー侵害や疑わしい活動に関する貴重な洞察を提供できます。
頑丈な認証を実装
ユーザーの身元を確認するための強固な認証メカニズムを実装します。前述のように、認証には OAuth 2.0 や OpenID Connect などの安全なプロトコルの使用を検討してください。詳細情報については、CIAM 101: 認証、Identity、SSO を参照してください。
頑丈な認可を構築（例えば、ロールベースのアクセス制御を実装）
認証に加えて、適切な認可メカニズムを設ける必要があります。ロールベースのアクセス制御（RBAC）を実装して、ユーザーが彼らが実行する権限を持つリソースとアクションのみにアクセスできるようにします。詳細情報については、CIAM 102: Authorization & Role-based Access Control を参照してください。
マルチファクター認証（MFA）を実装
マルチファ クター認証（MFA）は、ユーザーがパスワードとモバイルデバイスに送信されるワンタイムコードなど、一つまたは複数の形式の識別情報を提供することを要求することで、追加のセキュリティーレイヤーを提供します。MFA の良い例は、GitHub が利用者に対して、リポジトリを削除するような重要な操作を実行する際に、モバイルアプリからのワンタイムコードを入力するように求める場面です。
しかしながら、ほとんどの初期スタートアップ企業では MFA が必要ではなく、プラグアンドプレイ式のソリューションがない場合は、これが過度であると感じるかもしれません。これによって、ユーザー体験が否定的に影響を受ける可能性があります。
文化
上記で提供されたアドバイスのほとんどは、「受動的」なセキュリティー措置に関するものであり、それらはセキュリティーインシデントが発生する前に知っておくことができます。しかし、全体的なセキュリティー態勢を改善するために取ることができる「積極的」なセキュリティー措置もあります。これらは長期的にはより効果的です。
チームとユーザーにフィッシングとソーシャルエンジニアリングについて教育
フィッシング攻撃とソーシャルエンジニアリングは重要です。なぜなら、これらは上記で述べた多くのセキュリティー対策を無効化できるからです。例 えば、ユーザーがパスワードを渡したり、無害な猫の絵をクリックしたりするためにだまされた場合、あなたのパスワードハッシュアルゴリズムの強度やファイアウォールルールは関係ありません。
ほとんどの人々はセキュリティートレーニングを退屈で、それはしばしばそうです。そのため、チームとユーザーに教育する方法を変えます。例えば、実際の攻撃者がする前にフィッシングメールをシミュレーションし、それを識別する方法をデモンストレーションします。フィッシングメールをセキュリティーチームに報告するための報酬を提供することもできます。
DevSecOps を設定
手動のセキュリティーレビューに加えて、DevSecOps の慣行を導入してセキュリティーチェックを自動化することもできます。例えば、CodeQL などの静的コード解析ツールを実行する CI/CD パイプラインを設定したり、OWASP ZAP などのツールを使用して自動的に侵入テストを実行したりできます。
ユーザーエクスペリエンスに影響を与えずに最も厳格な設定を導入
セキュリティーに関しては、ユーザー体験にネガティブな影響を与えない最も安全な設定を常に選択します。便利さのためにセキュリティーを妥協したり、近道を取ったりすることは避けます。セキュリティーは常 に最優先事項でなければなりません。
スタートアップや個人開発者として、これらの対策を実装するための必要なリソースが欠けていると感じるかもしれません。それにも関わらず、無料またはスタートアップに優しいオプションを提供するプロフェッショナルなセキュリティーサービスが提供されています。これらをレビューし、利用を検討する時間を取ってください。
結論
セキュリティーは複雑なトピックであり、一つの記事で全てを網羅することは不可能です。この記事があなた自身やあなたのチームのセキュリティー感を強化するのに役立つことを願っています。新しいアプリを作成している場合、Logto という、製品のユーザー識別を最小限の労力で開発、管理、保護するのに役立つプラットフォームをチェックしてみても良いでしょう。