安全な認証のためのプレイブック
クレデンシャルスタッフィングや同様の攻撃手法の台頭により、ユーザー名とパスワードによる単純な認証では攻撃を抑止できなくなっています。Verizonのデータ侵害調査レポートによると、2018年に55,000件以上セキュリティインシデント、2,200件のデータ侵害が確認されました。これらのインシデントの81%は窃取されたパスワードや弱いパスワードに関連して発生しました。
データ侵害の急増と消費者からの信頼の喪失に伴い、Webアプリケーションのセキュリティ態勢の見直しが企業に迫られています。そのためには、まず安全性のより高い認証方法を探索する必要があります。
この記事では、現在一般的な認証方法の種類について説明し、それらを最善の形で実装するためのヒントを紹介します。
認証方法における認証と承認の違い
最初に明確にしておきたいのは、「認証」とはアイデンティティを検証する行為を指すという点です。つまり、ユーザーが本人の主張どおりの人物であることを確認することです。最も一般的でシンプルな例としては、ユーザー名とパスワードを使用して銀行口座などのアプリケーションにアクセスする場合の認証があります。
しかし、アプリのセキュリティが話題に上るときは往々にして、認証と承認の概念（認証とは？）が混同されたり、2つが同じ意味で使用されたりすることがあります。実際には、2つは独立した個別の概念であり、両者の違いを理解することが重要です。
Webアプリにおける認証は、システムがログイン資格情報をチェックしてユーザーを認識するかどうかを判断し、ログインする必要があることを確認するときに行われます。一方、承認は、コンテンツの表示、編集、削除、または作成をユーザーに許可するかどうかについて、システムがアクセス制御のアクセス許可内で確認するときに行われます。
2つの違いが明確になったところで、本題に入りましょう。
認証方法の種類 どのような認証方法があるのか
一要素認証
プライマリ認証とも呼ばれ、最も単純で最も一般的な形態の認証です。当然ながら、一要素認証で必要な認証方法は1つだけです。たとえば、パスワード、セキュリティPIN、PIVカードなどにより、システムやサービスへのアクセス権を付与します。
これらの認証方法は、ユーザビリティに優れ、非常に親しみやすいものである一方で、一般的には貧弱なセキュリティに紐付けられ、データ侵害、フィッシング、またはキーロガーを介して容易に推測/窃取される可能性があります。
二要素認証
2FAは、ユーザーのアイデンティティを検証するための2番目の要素を要求することで、より複雑化した強固なレイヤーを追加します。一般的な例には、登録デバイスによって生成されたトークン、ワンタイムパスワード、PIN番号などがあります。2つの認証方法を使用するだけで、セキュリティ態勢が大幅に向上します。実際のところ、Symantecの調査では、データ侵害の80%を2FAで防止できることが報告されています。
2FAのセキュリティ上のメリットについて多くの文書が作成されている一方で、採用は広範囲にわたる問題となっています。Googleが最初にアカウントに2つの認証方法を適用するオプションを導入したときは、7年以上にわたって、2FAを採用したユーザーの割合は10%未満でした。Googleによると、2FAを求めない理由の1つは、ユーザーの利便性を損なうというものでした。特に、2FAを試したユーザーの10%以上は、SMS認証コードを正しく入力できませんでした。
多要素認証
多要素認証（MFA）は、2つ以上の独立した要素を活用してシステムへのアクセス権をユーザーに付与する、最も高度な認証手法です。一般的なシナリオでは、MFA（MFAとは？）手法は次のカテゴリーから少なくとも2つまたは3つを利用します。
- ユーザーが知っている情報：パスワードまたはPIN
- ユーザーが所持するもの：携帯電話またはセキュリティトークン
- ユーザー自身であるもの：指紋またはFaceID
- ユーザーが実行すること：タイピングの速さ、位置情報など
認証手法プロトコル
一般的に、ユーザー名/パスワードと多要素のいずれか、または両方を使用する認証手法は、安全であると見なされます。しかし、認証の双方向モデルを破壊する認証シナリオがあります。
一般的な認証方法の例として、既存サービス（モバイルデバイス、別のWebサイト、またはデスクトップアプリ）から外部のサードパーティサービスにアクセスする場合があります。たとえば、銀行口座をサードパーティの資産管理プラットフォームにリンクするケースが該当します。
このようなシナリオで、資格情報を保存する可能性があるサードパーティアプリケーションとの間で認証方法を共有することは、安全でも賢明でもありません。資格情報の保存によって攻撃対象領域が拡大し、ユーザーには資格情報に対する侵害攻撃のリスクが生じます。
ユーザーデータを攻撃者に公開するのを防ぐためには、OAuth、OpenID、SAML、FIDOを含め、実装できる認証プロトコルがいくつかあります。
では、API認証は？
APIエコノミーの時代において、APIは大量のデータを処理し、オンラインサービスのセキュリティ領域に新たな次元を追加します。API認証方法は多くありますが、そのほとんどは以下の3つの認証方法のいずれかに分類できます。
HTTP基本認証
このアプローチを使用する場合、ユーザーエージェントは認証を証明するためのユーザー名とパスワードを提供するだけです。HTTPヘッダー自体を利用するので、Cookie、セッションID、またはログインページは必要ありません。この認証方法は簡単に使用できますが、転送中にユーザーの資格情報をキャプチャする可能性のある攻撃に対して脆弱です。
APIキー
APIキーは、Webサービス要求（または類似の要求）の発信元を特定するための識別子です。キーは、ユーザーが登録を通じてシステムへの承認されたアクセスを初めて試みるときに生成されます。その時点から、APIキーはシークレットトークンに関連付けられ、その後の要求と一緒に送信されます。ユーザーがシステムに再びアクセスしようと試みるとき、一意のキーによって以前と同じユーザーであることを証明します。このAPI認証方法は非常に高速で信頼性が高い一方で、頻繁に不正使用されます。さらに重要なのは、この認証方法が承認の方法ではないという点です。
OAuth
OAuthは最も安全なAPI認証方法の1つであり、認証と承認の両方をサポートします。OAuthにより、APIは範囲を確立することで認証し、要求されたシステム/リソースにアクセスできます。これは、APIを認証する上で根本的に非常に安全な手段です。
ユーザーエクスペリエンスを高め、攻撃のリスクを低減する認証
認証のあり方が変わりつつある今、転換期を迎えています。FaceID、TouchID、Windows Helloなどのユーザーデバイスに組み込まれた生体認証システムによって、オンラインサービスでのユーザー認証方法は今後も変化し続けていきます。
将来を見据えたビジネスは、ユーザーエクスペリエンスを向上させ、フィッシング攻撃の成功率を低下させる手段として、パスワードからの移行を模索し、API認証を改善しています。より安全な認証方法を組み込むことで、攻撃者が脆弱なパスワードを悪用できなくなります。
Oktaを利用して優れた安全な認証エクスペリエンスを実現するための詳細については、Customer Identityに関する認証のページをご覧ください。
Follow Jack Shepherd
