コンテンツにスキップ 
ホスティング利用者は、ブルートフォースアタックやクレデンシャルスタッフィングなどの攻撃からホスティングアクセスを保護するために、技術的なパスワードセキュリティ対策を一貫して実施する必要があります。この記事では、サーバ側でクラビティ防止ポリシーを実装、実施、監視する方法について、実践的な適用のためのベストプラクティスを含めて紹介します。特にホスティング・サーバの場合、脆弱なパスワードは、攻撃者がウェブサイト全体を侵害したり、機密データを盗んだりするための入り口となる可能性があります。重要なガイドラインが守られていなかったり、実装されていなかったりしたために、簡単なパスワードが短時間で解読されてしまうのをよく目にします。強固なパスワード・ガイドラインとベスト・プラクティスを日常生活で実践するために必要な労力は、一度明確に定義され、技術的に統合されれば管理可能である。
中心点
- パスワードポリシー 管理インターフェイスで直接定義し、実施する
- 多要素認証 重要なアクセスポイントをアクティブに保護
- パスワードハッシュ bcryptまたはArgon2で保存データを保護
- 自動チェック 漏洩したアクセスデータに対して
- GDPR対応 パスワードガイドラインの文書化
賢明なパスワードガイドラインを一貫して実施する
機密性の高いホスティングエリアの保護は、効果的なパスワードルールの定義と実装から始まる。よく考え抜かれた技術的実装は、アカウントが作成されると同時に、弱い組み合わせが除外されることを保証します。最小限の長さ、複雑さ、試行失敗時のブロック機能をシステム側で有効にする必要があります。少なくとも以下のガイドラインを推奨する。 14文字 の長さ、特殊文字や大文字の使用を強制する。さらに、システムは古いパスワードや一般的なパスワードを自動的に拒否する必要がある。 このようなガイドラインをユーザーフレンドリーにするために、パスワードヒントを入力時に直接表示することができます。こうすることで、ホスティングを利用する顧客は、例えば色付きのインジケータ（赤、黄、緑）によって、自分の選択が要件を満たしているかどうかをすぐに確認することができます。私は、多くのホスティング業者がパスワード規則について言及しているが、必ずしも明確に実装していないことに気づいた。一方、顧客インターフェースまたは管理者インターフェースに一貫して統合することで、パスワードを割り当てる際のエラーを大幅に減らすことができます。 ポリシーの定期的な見直しも重要な役割を果たします。脅威のシナリオが変わったり、新しい攻撃ベクトルが追加されたりすることはよくある。パスワードの強度や最小限の長さの要件を随時更新する価値はある。これにより、既存のホスティングアカウントを必ずしも危険にさらすことなく、セキュリティレベルを最新の状態に保つことができます。安全なパスワードポリシーの技術的実装の仕組み
ホスティング環境では、パスワードのセキュリティはサーバーサイドのポリシーによって最も効率的に実現できる。これには、パスワードの入力や変更時のパスワード検証のためのモジュールも含まれる。使用されるシステムは、パスワードが入力されたときに、プレーンテキストの長さ、文字の種類、既知のパスワードリークとの一致をチェックするように設計されている必要があります。ここでは、次のような安全なハッシュ法を使う価値がある。 Argon2またはbcrypt 理想的には、さらなるセキュリティのためにハードウェア・セキュリティ・モジュールを搭載することだ。 また、失敗した試行を厳密に記録し、異常が発生した場合は一時的にアカウントをブロックすることをお勧めする。これにより、ブルートフォース攻撃の可能性を、攻撃者がアクセスに成功する前に余裕をもって認識することができる。ログを一目見るだけで、特定のIPアドレスやユーザーアカウントが際立って頻繁なアクセス試行を引き起こしているかどうかの情報をすでに得ることができる。 もう1つの重要な要素は、cPanel、Plesk、またはプロプライエタリなホスティング・インターフェースなどの既存の管理システムへの統合である。パスワードポリシーと検証メカニズムがアプリケーションレベルでしか有効化されない場合、多くの場合、それは遅すぎ、ユーザーはすでにパスワードを割り当てている。そのため、ガイドラインはサーバー側で実装し、実施する必要があります。例えば、ホスティングコントロールパネルにシームレスに統合できる特別なプラグインや統合モジュールを使用します。スクリーンロックだけでは不十分 - MFAが必須
古典的なパスワードの使用だけでは、ホスティングアクセスにはもはや十分ではありません。ホスティングをご利用のお客様には、さらに以下の方法でアカウントを保護するようにしています。 多要素認証 を保護することができる。最適な2ファクタ・ソリューションは、静的ログインと動的に生成されるコードを組み合わせたもので、例えばアプリや物理的なセキュリティー・トークンを利用する。MFAを一度正しく設定すれば、パスワードが漏洩した場合でもアクセスを防ぐことができる。 私の経験では、Google AuthenticatorやAuthyのようなアプリベースのソリューションとの組み合わせが特に人気がある。しかし、特にセンシティブな環境では、ハードウェアトークン（YubiKeyなど）をお勧めする。スマートフォンのアプリとは異なり、モバイルデバイス上での改ざんからさらに保護することができるからだ。復旧プロセスを計画することが重要です。トークンを紛失したり破損したりした場合、攻撃者に悪用されることなくアクセスを回復するための安全な手順が必要です。 ホスティングパネルへのログインだけでなく、データベースや電子メール管理など、他のサービスに対してもMFAを実施するようにすべきである。特に電子メールの分野では、電子メールには経営陣や顧客とのコミュニケーションが含まれていることが多く、悪用されてはならないにもかかわらず、二要素認証が使用されることはまだあまりに少ない。
パスワードの推奨最低要件
以下の概要を見れば、基本的な規格の概要を理解し、ホスティング・プラットフォームに統合することが容易になる：| カテゴリー | 必要条件 |
|---|---|
| 最小の長さ | 最低12文字、できれば14文字以上 |
| 複雑さ | 大文字/小文字、数字、特殊文字の組み合わせ |
| 使用期間 | 90日ごとの更新（自動化可能） |
| 回避 | デフォルトのパスワードやパスワード要素（123、admin）がない |
| ストレージ | bcryptまたはArgon2で暗号化 |
パスワードローテーションツールとアクセスコントロールツール
専門的なソフトウェアにより、ホスティング管理者は特権アカウントアクセスを自動的に変更することができる。Password Manager Proや同様のプラットフォームのようなツールは特に有用である。これらのプログラムは、サービスアカウントのパスワードを定期的にローテーションし、変更を文書化し、重複を防ぎ、セキュリティ違反を迅速に報告する。また、監査可能なログとプロトコルを保持することを推奨する。これは、運用面でも、第三者による監査時にも役立つ。 大規模なホスティング環境や大手顧客向けには、一元化されたID・アクセス管理システム（IAM）を使用することができる。これは、役割コンセプトを定義し、役割に基づいて異なるパスワードとMFA要件を強制するために使用される。例えば、管理者には一般ユーザーよりも高いセキュリティ・レベルが適用される。導入時には、すべてのインターフェースが正しく接続されていることを確認することが重要である。また、オフボーディングも過小評価されがちです。従業員が退職した場合、そのアクセスは直ちに無効化または再割り当てされなければなりません。 パスワードベースのアクセスに加えて、ホスティング環境におけるSSHキーの管理も重要である。多くの場合、SSHアクセスのパスワードレス認証を推奨しているが、鍵が漏洩した疑いがある場合は、鍵も安全に保管し、ローテーションしなければならない。最悪のシナリオでは、盗まれたSSH鍵は検知されないアクセスにつながる可能性があり、これはクラックされたパスワードの使用よりもはるかに検知が困難である。誤ったパスワード管理の落とし穴を認識し、排除する。
明確なガイドラインがあるにもかかわらず、実際には同じような弱点が繰り返し見られる。パスワードを電子メールや暗号化されていないメモ、フリーテキストファイルに保存しているケースなどだ。同じパスワードを複数のサービスに使ったり、安全でない経路でアクセスデータを渡したりするユーザーもいる。このような行為に対抗するため、私はパスワードの一元化を強く提唱している。 管理およびセキュリティ対策 より。 特に、管理者が自分のプライベート・パスワードをビジネス・アクセスに悪用したり、その逆をしたりすると厄介になる。漏洩したプライベート・アカウントは、たちまち会社のリソースへのゲートウェイになりかねない。ホスティング・プロバイダーが定期的にこうした危険性を顧客に知らせることは重要だ。トレーニング資料、ウェビナー、または顧客エリアにある短い説明ビデオは、ここで素晴らしい効果を発揮します。 私はまた、パスワードの頻度、複雑さ、変更間隔について明確なガイドラインを提供しているNIST SP 800-63Bのような標準に従っています。特に最も機密性の高いデータをホストしている企業は、明らかな攻撃ポイントを閉鎖するために、少なくともこれらのガイドラインに従うべきである。
実例：ホスティング・プロバイダーのパスワード要件
webhoster.deのようなますます多くのホスティング業者が、定義済みのパスワードルールに頼っていることに気づきました。顧客は自分のパスワードを自由に選ぶことができず、代わりにサーバーが直接生成した安全な組み合わせを受け取ることになります。これにより、操作されやすい設定は完全に排除されます。さらに、ログインのたびに、少なくとも2つの要素を使った認証が必要となる。これらのプロバイダーは、アカウント作成時やパスワード変更時の自動チェックをすでにサポートしている。 いくつかの自動生成の欠点は、ユーザーがこれらのパスワードを記憶するのが難しいことである。このため、便利なパスワード・マネージャーがカスタマーセンターで提供されることが多い。これにより、顧客はログインするたびに長い文字列を入力する必要がなくなり、代わりに安全なシステムを使って便利にログインすることができる。このようなサービスは、直感的で安全であり、パスワードが電子メールでプレーンテキストとして送信されないことが重要である。 しかし、ごく初歩的な保護しか実装していないプロバイダーもまだ存在する。MFAを使用する義務がない場合もあれば、パスワード入力時の失敗回数に制限がない場合もある。顧客はここをよく見て、必要であれば、現行のセキュリティ基準に準拠した別のサービスを選ぶべきである。技術的対策によるGDPR対応
EUのGDPRでは、データ保護に関連するシステムは適切な技術的手段によって保護されなければならないと規定されています。ホスティングサービスを運営または利用する者は、文書化されたパスワードポリシーを証拠として提出することができる。パスワードの自動ローテーションや監査ログもTOMの一つである。よく実施されたパスワード管理は、セキュリティをサポートするだけでなく、監査時に規制上の証拠となる。 GDPR監査では、パスワードの概念が欠けていたり不十分だったりすると、高額な警告や罰金につながる可能性がある。したがって、早い段階でセキュリティ・アーキテクチャに組み込み、定期的に見直すことをお勧めする。正確な文書化の重要性は過小評価されがちです。パスワードはどのくらい複雑であるべきか、どのサイクルで更新が行われるか、アカウントがロックされるまで何回の試行失敗が許されるか、などを明確に記録しておく必要がある。この情報は、監査やセキュリティ・インシデントが発生した場合に、決定的なアドバンテージとなる。 パスワード保護の話題は、DPO（Data Processing by Order：命令によるデータ処理）に関しても関連する。プロバイダーは契約上、適切な予防措置を講じることを保証すべきである。そうでなければ、パスワードが漏洩した場合、顧客はすぐにグレーゾーンに陥ることになる。
ホスティング・カスタマーに対する組織の推奨事項
技術的なセキュリティには、組織的な部分も含まれます。特にフィッシングやソーシャル・エンジニアリング、パスワードの再利用に関しては、定期的に全ユーザーを訓練するようホスティング業者にアドバイスしている。また、パスワードポリシーが文書化され、実施されているプラットフォームを選ぶべきです。これには、例えば、MFAの有効化やサーバー側のパスワード指定のオプションが含まれる。安全面を重視するのであれば、一元化されたパスワード・マネージャーを使用し、個々のルールの定期的なチェックに頼るべきである。 特に多くの従業員を抱える企業では、パスワードガイドラインを明確な内部プロセスで補完する必要がある。これには、新しいアカウントの割り当て、ゲストアクセスへの対応、管理ログインの保護などのガイドラインが含まれる。また、データベースや顧客データなど、特に重要なアクセスを割り当てる場合は、二重管理の原則を推奨する。こうすることで、内部脅威のリスクを軽減し、ヒューマンエラーを排除することができる。 パスワードの使用に関する社内FAQやウィキを作成するのも有効だ。ユーザーはそこで、パスワードの回復方法やMFAの設定方法に関するヘルプを見つけることができる。このセルフヘルプの提供は、サポートチームの負担を軽減するだけでなく、従業員の自主的で責任あるセキュリティ文化を促進する。パスワード保護とWordPress：CMSアクセスの特殊なケース
実際には、多くのウェブ・プロジェクトがWordPressや同様のCMSプラットフォームに依存している。特に、ブルートフォース（総当り）を使ったバックエンドへの攻撃などが、しばしば試みられています。したがって、ホスティング・インフラを保護するだけでは不十分で、アプリケーション・アクセスも保護する必要がある。良い選択肢は 簡単な方法でWordPressログインを保護する.これには、IPブロック、レート制限、二要素法によるログインなどが含まれる。 私自身の経験から、多くのWordPressインストールは、テーマとプラグインに焦点が当てられていることが多いため、ほとんど保護されていないことを知っている。不審なログイン試行をブロックしたり、攻撃時に管理者宛のメールを送信したりする、セキュリティ関連のプラグインをインストールするのは理にかなっている。また、デフォルトのログインURLを変更し、IPホワイトリストを使用すれば、攻撃対象は大幅に減少する。ホスティングをご利用のお客様には、WordPressサイトをよりセキュアにするために、このような追加のステップを踏むことを常にお勧めしています。 WordPressや他のCMSは高度にモジュール化された構造を持っていることが多いので、それぞれのプラグイン・インターフェイスを見てみることも価値がある。セキュリティプラグインの中には、弱いパスワードを認識したり、既知の漏洩データベースと照合したりする統合パスワードチェック機能をすでに提供しているものもある。セキュリティのレイヤーが多ければ多いほど、潜在的な攻撃者にとっては難しくなる。
多層セキュリティ・モデルの一部としてのパスワード
従来のパスワードが将来完全になくなることはないだろう。バイオメトリック要素やFIDO2のようなパスワード不要のログイン手順を統合するプロバイダーはますます増えていくだろう。しかし、これらの方法を用いても、バックアップ・アクセス、管理者アカウント、APIアクセスの安全な処理は 強力なパスワード 不可欠である。したがって、それは代替物ではなく、補完物なのだ。私は、これらの技術が意識的に組み合わされ、技術的に確保されていることを確認している。 重層的なセキュリティ・コンセプトのためには、パスワード、MFA、ファイアウォール、定期的な監査、侵入テストが手を取り合って行われるべきである。一つの要素が他の要素を完全に置き換えることはない。例えば、パスワードはIPフィルタリングメカニズムによって保護することができるが、MFAは効果的なアクセス障壁を大幅に増加させる。同時に、不審なアクセスや失敗した試みをリアルタイムで認識し、ブロックするために、包括的なロギングとモニタリングのコンセプトが必要である。 場合によっては、生体認証（指紋、顔認証）も追加できる。しかし、管理者と対応するデバイスが常にシームレスに利用できるとは限らないため、ホスティング環境での受け入れは低いことが多い。最終的には、どの方法が運用環境に最も適しているか、現実的なメリットがデメリットを上回るかを段階的に評価することが望ましい。ウェブアプリケーションも適切に保護する
私はすべてのホスティングのお客様にお勧めします、 常に安全なウェブアプリケーション - ホスティング・レベルだけでなく、アプリケーション・レベルでも。多くの攻撃は、ホスティング・プラットフォーム上で直接発生するのではなく、保護が不十分なウェブ・バックエンドを介して発生する。パスワード、2ファクタ、IPフィルタ、セキュリティログなど、多層的なセキュリティが鍵となります。これを積極的にサポートするプロバイダーは、ユーザーが安定した信頼できるホスティングを利用できるようにします。 特にカスタマイズされたウェブアプリケーションは、認証にギャップがあることが多い。安全なパスワードリセットプロセスを確立する必要があります。パスワードをリセットするユーザは、リンクやコードが自動的に送信される前に十分に確認されなければなりません。うまく設定されたウェブアプリケーションファイアウォール（WAF）は、SQLインジェクションやクロスサイトスクリプティング攻撃をブロックすることもできる。 問題のCMSやフレームワークにかかわらず、すべてのコンポーネントとプラグインの定期的なアップデートは必須です。古いバージョンのソフトウェアは、強力なパスワードでも補えないセキュリティ脆弱性の温床となる。私は、ステージングシステムを伴う固定アップデートサイクルを推奨する。これによって、アップデートを本番前にテストすることができる。こうすることで、パッチのたびに本番システムを危険にさらすことなく、アプリケーションを最新かつ安定した状態に保つことができる。
