どーも、ばぁどです。 セキュリティエンジニアやっています。 元々はWebアプリ開発をやっていました。 現在は脆弱性診断を主にやっております。
最近、プライベートでAmazon Cognitoを利用したアプリケーションを触るタイミングがありました。 前から、Amazon Cognitoの存在はなんとなく知っておりましたが、少し調べてみるとサイバーセキュリティ的な観点で「あぁ脆弱性がなくなる良いものだ」と言う感想を持ちました。
物は作り込まない方が脆弱性は入り込まないと言う鉄則
筆者がWebアプリ開発者として、Webアプリを開発していた頃のお話です。 「自身が作るよりもライブラリなどに任せた方が結果的に安全なWebアプリケーションが作れる」と言う旨の発言をする同僚がいました。 当時の筆者は、あまり理解できていなかったのですが今なら概ね同じ意見であります。
例えばWebアプリケーションのモデル層で、DBを操作するSQLを発行する場面。 今ならDBを操作するSQLを発行するためのライブラリは多くの言語、フレームワークで採用されており、それらのライブラリを正しく扱えば、SQLインジェクションなどの脆弱性は基本的に防ぐことが可能です。
クロスサイトスクリプティングなども同様に、フロントエンド側の技術を正しく扱えばエスケープ処理を施した上で画面への描画が可能です。
これらは誤解を恐れずにいうと、利用ライブラリがOSSとなっており幾人もの凄腕エンジニアの方々のチェックが入ることから脆弱性が存在しないことが担保されています。
この既に作られているライブラリの安全性を理解していないと、自前のライブラリを使うとか、社内独自のフレームワークという発想になり、そもそもそこに脆弱性が存在していて、脆弱性だらけのWebアプリケーションを量産するという構図になっている企業を稀に見ます。
基本的には「作り込まない方が脆弱性は入り込みません」。
Amazon Cognitoが脆弱性を入れ込まないと言う面でも素晴らしい
さて、Amazon Cognitoのお話になります。 Amazon Cognito とは awsが提供するサービスの一つになります。
Amazon Cognito は、ウェブおよびモバイルアプリの認証、承認、およびユーザー管理機能を提供します。ユーザーは、ユーザー名とパスワードを使用して直接サインインするか、Facebook、Amazon、Google、Apple などのサードパーティーを通じてサインインできます。 Amazon Cognito の主な 2 つのコンポーネントは、ユーザープールと ID プールです。ユーザープールは、アプリユーザーのサインアップとサインインオプションを提供するユーザーディレクトリです。ID プールは、AWS の他のサービスに対するアクセスをユーザーに許可します。ID プールとユーザープールは別々に使用することも、一緒に使用することもできます。
要するに、Amazon Cognitoを用いることでログイン処理(認証、承認)を比較的工数をかけずに作成することができます。 ログイン処理ということなので、もちろんユーザ管理機能や各種アカウントとの連携なども可能です。
ログイン処理(認証、承認)は一定の力量を持つエンジニアが設計、開発しなければならない
ログイン処理とは、会員制のWebアプリケーションを使用する際に、そのWebアプリケーションに”誰が”、”どういった権限”で利用するかのチェック機構になります。 ユーザID、パスワードを入力した際に、ユーザID はテーブル内に存在するか？パスワードは合っているか？などのチェック機構が基本的に入ります。 ユーザID及び、パスワードが合っていて初めてログインを行うことができます。
しかしログイン処理は、Webアプリケーションを利用していないユーザでもアクセスすることができる重要なシステムです。 例えば、存在しないIDを入力した際に出すエラーメッセージと、既に存在するIDを入力した際に出すエラーメッセージを工夫しないと、攻撃者に対してユーザ情報について教えてしまう可能性があります。
このように、ログイン処理は一定の力量を持つエンジニアが開発しなければ、攻撃者にとって絶好の攻撃ターゲットになってしまうことは想像に難くありません。
また、ID連携機能は更に高い技術力が求められます。 Open ID Connect などの企画はありますが、それらの仕様を把握した上でテーブル設計を行い、漏れなくロジックを書くことによって初めて実現されるのが他システムとのID連携になります。 正直筆者も実装を行うとなうと、身震いしてしまうくらいには避けたいシステム内容です。
Amazon Cognitoが素晴らしい。
そこでAmazonから提供されている、Amazon Cognitoです。 Amazon Cognitoを用いれば上記の本来はログイン機能を実装する際に考慮しなければいけない内容を考慮せずに、Amazonのデファクトスタンダードに合わせてログイン機能を用いることができます。
ログイン処理を開発する際に考慮するべき、ユーザのテーブル設計などもAmazonが用意してくれています。 この考えなくて良いというのと、あらかじめセキュリティが担保されているというのは、Webアプリ開発の知見を持たないベンチャー企業にはとても有益なのではないでしょうか。
正直エンジニアとしての経験をまともに3〜5年くらい続けていればログイン機能の一つや二つは開発する機会はあるでしょう。 しかしセキュアなログイン機能を完璧に開発できるかは、その当時の仕様やソースコードのチェック体制にも絡んでくる要素であり、筆者自身もセキュアなログイン機能を実装するのは可能ですが、大きな工数が必要になります。 こういった工数削減という面から見てもAmazon Cognitoは非常に有益です。
また、ログイン時のパスワードのポリシーなども既に用意されているものを扱えば、基本的には安全なものになります。 例えばパスワードの最低文字数、最長文字数や文字種別などです。
脆弱性診断のタイミイングでこれらの要件に不備があることを指摘されても、管理コンソールから設定を修正することでセキュアなログインポリシーの反映ができます。 これを自前で開発していると、if分を追加したりだとか、エラーメッセージをどのように表示するかなどを考える必要があります。
こういった点から、Amazon Cognitoなどを利用した方がセキュアなログイン機能を得ることができ、とても有益だと筆者は考えました。
新しい技術は正しく採用することが吉である。
筆者個人的な感想ですが、新しい技術は正しく採用していくことは吉だと考えています。 特にAmazon Cognitoのように、採用するだけで一定のセキュリティを担保できるような技術は採用の価値は十分にあるでしょう。 個人的にはAmazon Cognitoの管理画面上で、セキュリティポリシーなどをチェックボックスで入力することで変更できる部分はとても感動しました。（まぁそりゃそうなのだが）
しかし技術選定はケース by ケースであり、 こういった最新の技術を使用するのが会社のルール的に難しい場合もあれば、 どうしてもAmazon Cognitoの仕様がWeアプリケーションの仕様とマッチしない場合もあるでしょう。
そういった場合は、自身の置かれている環境と、新しい技術のメリット/デメリットを考慮した上で、採用を検討してもらえればと思います。
