会社のブログログイン登録スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。214件3プライベートネットワーク内にサーバー(192.168.0.100)があり、dockerでmongodbサーバーを建てたとします。外部に公開する予定はなく、公開する方法も理解できていません。限った話ではなく、パスワードに対する考え方になりそうです。さんの回答と似通っていますが、ちょっと違う回答です。現実問題としてパスワードの有無でリスクがあまり変わらないケースというのはあると思います。リスクの有無を正確に判定するのは結構高度な技量が必要ですし、その判断を間違う可能性も高いです。「DBのパスワードを設定する手間」に比べて「DBにパスワードを設定しなくても安全と判断する手間」の方が大きいし、結局「判断が微妙だからパスワードを設定しておこう」という結論になりやすいです。現実にパスワード設定をしなかったために事故に至る例も結構あるようです。QiitaMongoDBを始めた頃に知っていたら、と思う14のことということで、DBにパスワードを設定するのは、習慣として身につけておいた方が良いと思います。このような疑問を持つこと自体は大切だと思いますよ。個の銅バッジ1徳丸先生にコメント頂けて感激です。今回は「判断が微妙だからパスワードを設定しておこう」という結論になりましたがdocker-composeに平文で書いていることが気になり、調べたら「環境変数として渡すのもリスク」と知りました。swarm」の知識が必要となる。学習コストがどんどん増えていって困惑しています。いえ知識として蓄えておいて損はないので、この際しっかり勉強したいと思います。アドバイスありがとうございました。|4リスクがあるか意味はあるか?という質問に関しては「すべてにリスクは存在します。意味はあります」という回答になってしまいます。悪意のある人間がプライベートネットワーク内に侵入してきた場合にはどうなるでしょうかDBの中身をすべてかっさらって逃げてしまうかもしれません。ローカルでしかアクセスしないと決めたサーバであってもそのサーバを丸ごと盗まれてしまったらどうなるでしょうか?あとでお家でゆっくり解体されてしまうかもしれません。誰かが設定をミスって、非公開のサーバのはずなのに公開の設定に変更してしまいいつの間にか筒抜けだったということもあり得ます。そんなこと考えていたらきりがないよね?と思うかもしれません。