Programmierer erobern Sicherheitsinfrastruktur als Code-Serie: Klartext-Speicherung von Passwörtern

セキュアなインフラストラクチャ・アズ・コードを組織内に導入する際、あなたはどのように取り組んでいますか？多少の学習曲線はあるかもしれませんが、ロープを学ぶことは、自分のスキルセットをレベルアップさせ、同僚の中で際立った存在になり、より多くのエンドユーザーのデータを安全に保つための大きなチャンスとなります。

最新の「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ブログページでは、この脆弱性について、また、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守る方法について、より詳しい情報をご覧いただけます。また、Secure Code Warrior トレーニングプラットフォーム内のIaC チャレンジのデモを試すことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。