Coders Conquer Security Infrastructure as Codeシリーズ：パスワードの平文保存

組織内でセキュアなInfrastructure as Codeを導入する際、現状はいかがでしょうか？習得には多少の学習が必要かもしれませんが、基本を身につけることはスキルアップを図り、周囲と差をつけ、そしてエンドユーザーのデータをより安全に守る絶好の機会となります。

「Coders Conquer Security」シリーズの次の章に進む前に、機密データ保存の脆弱性をテーマにしたゲーム形式のチャレンジに挑戦してみませんか？Kubernetes、Terraform、Ansible、Docker、CloudFormationの中から選んで、今すぐプレイしましょう。

結果はいかがでしたか？知識をさらに深めたい方は、ぜひこの先をお読みください。

今日のコンピュータセキュリティの要は、パスワードです。二要素認証や生体認証といった他のセキュリティ手法が導入されている場合でも、多くの組織では依然としてパスワードベースのセキュリティを保護手段の一つとして採用しています。多くの企業では、パスワードのみを使用しているのが現状です。

私たちはパスワードを多用するため、その作成ルールまで存在します。これはブルートフォース攻撃や推測による攻撃への脆弱性を減らすためのものですが、NordPassによる最近のレポートが示すように、依然として脆弱なパスワードを使用している人は少なくありません。2020年になっても「12345」や「chocolate」、「password」、「God」といった推測されやすい言葉で最も重要な資産を守ろうとする人がいるとは、信じがたいことです。

強力なパスワードの使用を気にしない人は常に存在しますが、多くの専門的な組織では、ユーザーに対して一定のルールに基づいたパスワードやフレーズの作成を義務付けています。今や、8文字以上で、大文字と小文字を組み合わせ、少なくとも1つの数字と特殊文字を含める必要があるというルールは周知の事実です。

問題は、ユーザーがどれほど強力なパスワード作成ルールを守っていたとしても、それらがすべてプレーンテキストで保存されていれば意味がないということです。ハッカーがパスワードファイル全体を読み取ることができれば、「12345」も「Nuts53!SpiKe&Dog12」も同様に危険です。

なぜパスワードをプレーンテキストで保存することが危険なのでしょうか？

パスワードをプレーンテキストで保存することは、システムとユーザーの両方を危険にさらすため非常に危険です。言うまでもなく、ハッカーがシステムへのアクセスに使用されるすべてのパスワードを読み取れる状態は壊滅的な事態を招きます。管理者の認証情報を入手されれば、システムやサイト全体が乗っ取られる可能性があります。しかも、ハッカーは正規のユーザー名とパスワードを使用するため、内部セキュリティシステムでは侵入を検知できないか、被害が拡大した後にようやく気づくことになります。

プレーンテキストで保存されたパスワードを攻撃者が盗みやすくすることは、ユーザーにも悪影響を及ぼします。多くの人がパスワードを使い回しているからです。パスワードの作成ルールが複雑化したことで、多くの人が覚えやすいパスワードを複数のサイトで使い回すようになっています。攻撃者がパスワードファイルを侵害すれば、ほぼ確実に同じユーザー名とパスワードを使って他のシステムへのアクセスを試みるため、ユーザーは二次被害に遭う大きなリスクにさらされます。

パスワードを誤ってプレーンテキストで保存してしまうことや、それが将来的に重大な問題を引き起こす可能性があることに気づかないことは、比較的よくあることです。例えば、Terraformテンプレートを使用してAWSリソースを定義する際、以下のようなコードでパスワードを保存するのはよくある手法です。

resource "aws_db_instance" "default" {
 engine                 = "mysql"
 allocated_storage      = 10
 instance_class         = "db.t2.micro"
 username               = "admin"
 password               = "s3.cr3t.admin.p2ss"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

この例では、AWSのMySQLデータベースインスタンスを管理するためのパスワードがプレーンテキストで保存されています。つまり、ソースコードリポジトリにアクセスできる人なら誰でも、このパスワードを読み取ったり、コピーしたりできてしまうのです。

パスワードの保護方法はフレームワークによって異なりますが、どのプラットフォームにも保護手段は存在します。例えば、MySQLのパスワードはAWS Secrets Managerのような安全なストレージに保存することができます。

resource "aws_db_instance" "default" {
 engine            = "mysql"
 allocated_storage = 10
 instance_class    = "db.t2.micro"
 username          = "admin"
 password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

この例では、TerraformテンプレートがAWS Secrets Managerサービスからパスワードを取得するため、テンプレートファイル内にパスワードがプレーンテキストで保存されることはありません。

パスワードを平文で保存せず、適切に保護する

パスワードは組織の鍵となる重要な情報であり、決して平文で保存してはなりません。組織内部の人間であっても、保護されていないパスワードの巨大なリポジトリにアクセスできるべきではなく、そのような運用を許容することも避けるべきです（現在は暗号化された認証情報の共有を可能にするパスワードマネージャーが多数存在するため、言い訳は通用しません）。また、悪意のある内部関係者がファイルを覗き見し、本来アクセス権のない情報に触れてしまうリスクも存在します。

外部からの攻撃を想定した場合、SQLインジェクションのような単純な脆弱性からデータベースのバックドアが見つかり、パスワードが保存されているディレクトリまでアクセスされてしまうという二重の被害を想像してみてください。このようなエラーが重なる事態は起こり得ないとお考えでしょうか？残念ながら、まさにこのシナリオが 2011年のソニーのデータ流出事件で発生しました。100万人以上の顧客パスワードが平文で保存されており、Lulzsecというハッカー集団が一般的なSQLインジェクション攻撃を通じて、それらを含む膨大なデータにアクセスしたのです。

すべてのパスワードは、利用可能なフレームワーク内の防御策を用いて保護する必要があります。Terraformの場合、テンプレートファイルにパスワードを記述してはなりません。インフラストラクチャプロバイダーに応じて、AWS Secrets ManagerやAzure Key Vaultといった安全なストレージを使用することを推奨します。

ユーザーに安全なパスワード作成を強制することは有効ですが、バックエンド側でも同様の対策が不可欠です。パスワードを平文で保存しないことは、ユーザーとシステムを守るための大きな一歩となります。平文保存の最大の危険性はアクセス制御の不備にあり、実質的に誰でも閲覧できてしまう点にあります。特にIaC環境では機密情報へのアクセス権を持つ人が増えるため、パスワードを適切にハッシュ化し、必要最小限の担当者にのみアクセス権を付与することが極めて重要です。

この脆弱性に関する詳細や、組織と顧客を他のセキュリティ上の脅威から守る方法については、Secure Code Warriorのブログをご覧ください。また、IaCチャレンジのデモをSecure Code Warriorのトレーニングプラットフォームで体験し、サイバーセキュリティのスキルを常に最新の状態に保つことができます。