歴史上、プランナーが自分たちのソリューションの質を過信したために、数え切れないほどの失敗が起きてきた。不沈タイタニックであれ、第二次世界大戦の難攻不落のマジノ線であれ、一つの解決策に過大な信頼を置くことは、何度も何度も恐ろしい大惨事を引き起こしてきた。
サイバーセキュリティの世界でもそれは同じだ。単一のソリューションでサイバーセキュリティを防御するのであれば、トラブルを招くことになる。
安全保障に対する単一のソリューションの危険性
この記事では、あるeコマース・プロバイダーで発生したあるケースを見てみよう。この企業はモバイルアプリ用に新しいログインAPIを構築した。認証リクエストのペイロードにパスワードの1024ビットRSA暗号化を要求することで、セキュリティを強化した。
これは良いアイデアだ。結局のところ、認証情報は人間が読めるものではないので、中間者攻撃はほとんど役に立たなくなる。Base64エンコードされ、RSA暗号化された文字列として表示される。認証リクエストは自分たちのアプリから来ているのだから、これはかなり良いアプローチだ。親指を立てる。
しかし...それだけではない。よくなかったのは、このセキュリティ対策がすべてだと考えたことだ。パスワードの最大失敗回数を強制するような対策でセキュリティを改善し続ける代わりに、彼らはただそれを出荷することに決め、他の開発作業に移ったのだ。
すべてがうまくいっているように見えるかもしれないが、彼らのソリューションには重大な欠陥があった。1024ビットの公開鍵は、JADXを使って彼らのモバイルアプリを逆コンパイルすることで簡単に観測可能だった。
公開鍵をローカル・ファイルに保存することで、攻撃者は好きなパスワードを循環させ、ターゲットの公開鍵に従ってそれらをすべて暗号化し、認証エンドポイントの安全性を最初に確保した作業を完全に取り消すことができる。
このエンドポイントには、失敗したパスワードの最大試行回数制限がなかったため、bash スクリプトを書いて、必要な数のパスワードのチェックを自動化しました。私はこのeコマース・プロバイダーに、問題を実証するために設定したパスワードまでの単純なカウントダウンで問題を証明した：
#!/bin/bash |
これが私のスクリプトの出力である：
Welcome 10 |
それを分解してみよう。において for ループの中で、この概念実証のために設定したパスワードに到達するために、どの桁の数字を挿入するかを知らせるウェルカムメッセージから始める。そしてパスワードと、それに続いてAPIに送られる暗号化された値を見る。(まさか、こんな簡単なパスワードを使うとは思わなかっただろう。)
最後に、パスワードチェックのAPIレスポンスを出力してみた。最初の6回は失敗のレスポンスが返ってくるが、最終的に私のハイパーセキュア（😉）パスワードである faster4wardAPIは通常の認証スコープで私を許可する。
RSAで暗号化された認証ペイロードもこれまでか...。
同じ轍を踏まないために
さて、問題を特定したところで、代わりに何ができるだろうか？さて、最初に私たちをここに連れてきた根本的な考え方の間違いから始めましょう。アプリケーションのセキュリティを確保するための特効薬はないからです！ 上記の具体的な例では、強力なRSA暗号化に加えて、他の対策も必要です。
- 暗号化キーが安全であることを確認してください。
- パスワード認証の最大失敗回数を設定し、アカウントをロックアウトする。
- リクエストレート制限を実施する。
インターネットに露出したシステムのセキュリティは、徹底的な防御の信条を受け入れなければならない：防御することが最も興味深いと思われる、あるいは明白であると思われるポイントだけでなく、ウェブプレゼンスの全表面領域にわたって複数の防御層を展開しなければならない。
幸いなことに、Linodeは私たちのプラットフォームに組み込まれた多くの素晴らしいセキュリティ機能を提供しており、いくつかの一般的な攻撃ベクトルに取り組むための多くの業界標準があります。これらのソリューションのいくつかはLinodeアカウントに適用され、いくつかはLinodeに直接適用されます。両方のタイプの保護を見てみましょう。
Linodeアカウントの管理者アクセスを保護する
もし誰かがあなたのLinodeアカウントに侵入できたら、ゲームオーバーです。Linodeに侵入するのは些細なことです。そのため、Linodeアカウントはセキュリティを考慮して作られています。デフォルトでは、すべてのLinodeアカウントは電話認証で保護されている必要があります。Linodeはまた、アカウント回復のためにセキュリティの質問と答えを設定する必要があります。
電話認証に加えて、時間ベースのワンタイムパスワード（TOTP）認証コードを使用して2要素認証を設定することもできます。アカウントに必須ではありませんが、2FAを有効にすることを強くお勧めします。パスワードとセキュリティの質問だけよりもはるかに安全で、電話認証コードよりもさらに安全です。
Linodeのパスワードを完全に回避する別のレベルのセキュリティが利用できます。サードパーティ認証（TPA）ソースを使用することができます。この方法を使うことで、選択したサードパーティのソース（現在はGoogleとGitHubがサポートされています）に安全なログイン方法を設定することができます。これにより、パスワードが漏れてLinodeアカウントにアクセスできなくなる可能性を減らすことができます。
アカウントを保護する最後の方法は、アカウントの特定の部分にアクセスできる特定のユーザーを設定することです。こうすることで、サブユーザーがあなたのアカウントでできることに一定の権限を設定することができ、攻撃者があなたのアカウントに無制限の損害を与える可能性をさらに減らすことができます。
このように、インフラ のさまざまな部分にアクセスするユーザー間の懸念を分離することを導入することは、良い習慣である。もちろん、あなたが1人のチームであれば、これは必要ないかもしれません。しかし、もし本当の意味での懸念事項の分離ができていれば、あなたのアカウントやインフラ に無許可の変更が加えられないようにすることができます。
Linodesのセキュリティ
アカウントの保護は確かに重要ですが、サーバーとインフラ の保護はさらに重要かもしれません。結局のところ、ほとんどの攻撃者はホスティングプロバイダを通してではなく、インフラ を通してインフラ に侵入しようとします。Linodeはここもカバーしています。
LinodeアプリMarketplace 。Haltdos WAFのようなセキュリティソリューションを導入してサーバーのゲートで悪意のあるトラフィックを阻止する必要がある場合でも、Prometheus + Grafana のセットアップのような監視スタックをワンクリックでインストールしたい場合でも、Marketplace よりもスタックのセキュリティと監視が簡単になることはありません。
自由に使えるソリューションはサードパーティのアプリだけではありません。LinodeCloud Firewallは、Cloud Managerから直接簡単に設定できる素晴らしいソリューションです。LinodeCloud Firewall とファイアウォールの両方をLinodeで使うのもいいアイデアです。
もう一つの良い習慣は、DDoS攻撃からサーバーを確実に保護することです。Linodeでは、デフォルトでこれらの攻撃から インフラ ！Linodeでは、デフォルトでこれらの攻撃からサーバー全体を守ることができます。
結論
セキュリティーについてもっと言いたいことはたくさんあるが、今はこれで十分だろう。全体として、一つの問題に対する巧妙な解決策に気を取られて、セキュリティ・アプローチに欠けている可能性のある他の事柄への配慮を忘れてしまわないようにしましょう。
コメント