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

2020年5月18日発行
マティアス・マドゥ博士著
ケーススタディ

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

2020年5月18日発行
マティアス・マドゥ博士著
リソースを見る
リソースを見る

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

最新の「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 チャレンジのデモを試すことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。


リソースを見る
リソースを見る

著者

マティアス・マドゥ博士

マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社(Sensei Security)などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング(courses )の講師も務めています。

Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

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

2020年5月18日発行
マティアス・マドゥ博士著

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

最新の「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 チャレンジのデモを試すことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。


弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。