シェルスクリプトでのパスワードの非表示

シェルスクリプトでパスワードを非表示にするにはどうすればよいですか？データベースにアクセスしているスクリプトは多数あります。スクリプトを開くと、他のユーザーもユーザー名とパスワードを認識します。だから誰かが非表示にする方法を知っているなら、私に知らせてください。

私は1つの方法があります：パスワードをファイルに入れて、ファイルを隠し、誰もファイルにアクセスしないようにします（データベースにアクセスする間、権限を変更し、スクリプトでファイルを使用します）。

最初に、すでに数人が言っているように、資格情報をスクリプトとは別にすることが不可欠です。（セキュリティの向上に加えて、資格情報が異なる複数のシステムで同じスクリプトを再利用できることも意味します。）

次に、資格情報のセキュリティだけでなく、資格情報が侵害された場合の影響も考慮する必要があります。データベースへのすべてのアクセスに1つのパスワードを設定するのではなく、異なるアクセスレベルで異なる資格情報を使用する必要があります。たとえば、データベース内で検索を実行できるDBユーザーを1人持つことができます。そのユーザーには読み取り専用アクセスが必要です。別のユーザーには、新しいレコードを挿入する権限がありますが、削除することはできません。3番目のレコードには、レコードを削除する権限があります。

各アカウントの権限を制限することに加えて、各アカウントを使用できる場所も制限する必要があります。たとえば、Webサーバーが使用するアカウントは、WebサーバーのIPアドレス以外のIPアドレスからの接続を許可されません。データベースへの完全なルート権限を持つアカウントは、実際に接続する場所に関して非常に制限される必要があり、対話以外で使用されることはありません。また、データベースのストアドプロシージャを使用して、各アカウントで実行できることを厳密に制限することも検討してください。

これらの制限は、システムのDBサーバー側に実装する必要があります。そのため、クライアント側が危険にさらされても、制限を変更することはできません。（そして明らかに、DBサーバーはDB構成に加えてファイアウォールなどで保護する必要があります...）

制限された読み取り専用アクセスのみが許可され、特定のIPアドレスからのみのDBアカウントの場合、データの機密性とホストのセキュリティに応じて、それ以上の資格情報は必要ない場合があります。から実行されています。1つの例として、Webサイト上の検索フォームがあります。これは、Webページに表示される情報のみを抽出するストアドプロシージャの使用のみが許可されているユーザーで実行できます。この場合、パスワードを追加しても実際には追加のセキュリティが付与されることはありません。その情報は既に公開されているため、ユーザーは機密性の高い他のデータにアクセスできないためです。

また、TLSを使用してデータベースへの接続が確立されていること、またはネットワークでリッスンしているユーザーが資格情報を取得できることを確認してください。

3番目に、使用する資格情報の種類を検討します。パスワードは単なる1つの形式であり、最も安全ではありません。代わりに、何らかの形式の公開/秘密キーペア、またはAD / PAMなどを使用できます。

4番目に、スクリプトが実行される条件を検討します。

対話的に実行する場合、パスワードを入力するか、秘密鍵または秘密鍵へのパスワードを入力するか、有効なKerberosチケットでログインする必要があります。つまり、スクリプトは資格情報は、ファイルから読み取るのではなく、実行時にユーザーから直接取得します。

Webサーバーから実行する場合は、Webサーバーの起動時に資格情報を設定することを検討してください。ここでの良い例はSSL証明書です。公開証明書と秘密鍵があり、秘密鍵にはパスワードがあります。Webサーバーに秘密鍵を保存することもできますが、Apacheの起動時にパスワードを入力する必要があります。また、物理カードやHSMなど、サーバーの起動後に削除またはロックできる何らかの種類のハードウェアに資格情報を保持することもできます。（もちろん、この方法の欠点は、何かが起こった場合、サーバーがそれ自体で再起動できないことです。システムが危険にさらされるリスクよりもこれを好むでしょうが、あなたの走行距離は変わるかもしれません...）

スクリプトがcronから実行されている場合、これは難しい部分です。誰かがシステムにアクセスできる場所にクレデンシャルを置きたくはありませんが、スクリプトがアクセスできるようにクレデンシャルを置きたくありませんか？まあ、まったく正しくありません。スクリプトの実行内容を正確に検討してください。データベースにはどのような権限が必要ですか？間違った人がそれらの権限で接続しても問題にならないように制限できますか？代わりに、他のユーザーがいるサーバーからではなく、誰もアクセスできないDBサーバーでスクリプトを直接実行できますか？もし、私は考えることができない何らかの理由で、あなたは絶対にしなければならない安全でないサーバ上で実行中のスクリプトを持っており、それがなければなりません 危険な/破壊的な何かをすることができるようになりました...今、あなたのアーキテクチャを再考する良い機会です。

5番目に、データベースのセキュリティを重視する場合、他の人がアクセスできるサーバーでこれらのスクリプトを実行しないでください。誰かがシステムにログインしている場合、彼らはあなたの資格情報を取得する可能性があります。たとえば、SSL証明書を使用するWebサーバーの場合、少なくとも理論的には、誰かがルートを取得してhttpdプロセスのメモリ領域にアクセスし、資格情報を抽出できる可能性があります。最近では、SSLを介してこれを実行できる攻撃が少なくとも1つあり、攻撃者にログインする必要さえありません。

また、SELinuxやapparmorなど、システムで利用可能なものを使用して、どのユーザーが何をできるかを制限することを検討してください。資格情報へのアクセスを取得できたとしても、ユーザーがデータベースへの接続を試みることさえ禁止することができます。

これがすべてやり過ぎのように聞こえ、あなたがそれをする余裕がないか、時間がない場合-私の（rog慢でエリート主義的な）意見では、データベースに重要なものや機密事項を保存してはいけません。重要なものや機密事項を保存していない場合、資格情報の保存場所も重要ではありません。その場合、パスワードを使用する理由は何ですか？

最後にあなたは絶対に資格情報のいくつかの種類を保存しないようにすることができない場合、あなたは資格情報は読み取り専用と根と根が所有する可能性があり、あなたのスクリプトがなければならないので、スクリプト（によってそうするように要求されたときに非常に一時的に所有権を付与することができないこと絶対に必要な場合を除き、rootとして実行し、データベースに接続しても必要になりません）。しかし、それはまだ良い考えではありません。

まず、最初にスクリプト内またはスクリプトと一緒にパスワードを保存することを避けるために何かを変更できる方法がある場合、それを行うためにあらゆる努力をする必要があります。ジェニーDの答えには、その効果に対する多くの良いアドバイスが含まれています。

それ以外の場合、パスワードを制限されたアクセス許可を持つ別のファイルに配置するという考えはほとんどそれです。たとえば、メインスクリプトからそのファイルをソースできます。

. /usr/local/etc/secret-password-here

メインスクリプトのアクセス許可を制限して、許可された人だけが実行できるようにすることもできますが、パスワード自体のみを制限されたファイルに保存することをお勧めします。そうすることで、コード自体の検査（機密性の高い秘密なし）、バージョン管理、スクリプトのコピーの容易化などが可能になります。

他の答えはどのように対処しましたが、私はどうかを検討します。ユーザーが接続しているデータベースの種類に応じて、それらのクライアントプログラムで既に使用されている適切なメカニズムを既に持っている可能性があります。その場合は必ず使用してください（私は考えている~/.mysqlrcか~/.pgpass）。

複数のユーザーがデータベースにアクセスして共有アカウントを使用して特定のクエリを実行できるようにしている場合は、おそらくそうすべきではありません。代わりに、データベース上にアカウントがあり、それらのアカウントに必要以上のアクセス許可がないことを確認します（おそらくそのほとんどを読み取り、書き込みアクセスはほとんどありません）。他の方法ではアクセスできない特定のテーブルで特定のクエリを実行する必要がある場合は、ストアドプロシージャを提供してアクセスSECURTY DEFINERを許可します。

上記のいずれでも資格情報を保存する必要がある場合は、他の回答をここで読んでください。

アクセスできない場所にパスワードを隠すという考えは、状況によっては問題ない場合があります。

情報が分離されている場合、それはファイルの単純な編集を意味します。たとえば、同僚とのコードレビュー中に、そのファイルは表示されません。ただし、アカウントにアクセスできる人は誰でも簡単にそのようなファイルを見つけることができます。のアクセス権が十分に制限されていない場合に文句~/.sshをssh言う単純な理由のために、私はそのような目的のためにサブディレクトリを使用しました~/.ssh。

ただし、このようなユーザー名やパスワードのちらつきを防ぐためにできることは他にもあります。

難読化：スクリプトの編集中にユーザー名またはパスワードを誰にも読み取らせたくない場合は、テキストに含めることができますが、プレーンテキストではなく難読化できます。難読化されたバージョンが十分に長く、誰かがそれを見るのを暗記できない場合、解読方法とキーが明白に見えてもそれを知ることはできません。もちろん、これはあなたのアカウントへのアクセス権を持つ誰かによってまだ簡単に回避されるでしょう。

GPGの使用：

システムのrootユーザーによる攻撃に対する完全な証拠ではありませんが、ファイルのユーザー名とパスワードのペアを暗号化しgpg、スクリプトがファイルのコンテンツを取得するようにします（そうでない場合は、パスワードの入力を求められる場合があります）キャッシュ/期限切れ）。私はggp-cardを使用して、ラップトップを置いたままカードを引き抜くと、ピンがまだキャッシュされていてもアクセスできなくなります。少なくとも、数分で20回実行すると、ピンを1回だけ提供する必要があります。

セキュリティは常に利便性（セットアップと使用）に反比例するようです。

bashスクリプトにパスワードを保存する方法はありますが、スクリプトを暗号化および難読化して、誰も実際にそれを読み取ったり、スクリプトを実行したりして、正確に何をしているのかを確認できないようにする必要があります。bash / shellスクリプトを暗号化して難読化し、実際に実行可能にするには、ここにコピーして貼り付けてみてください。

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

上記のページで、あなたがしなければならないことは、あなたのスクリプトを提出することです（あなたの心の安らぎのために最初にサンプルスクリプトを提出できます）。zipファイルが生成されます。ダウンロードリンクを右クリックし、提供されたURLをコピーします。次に、UNIXボックスに移動して、次の手順を実行します。

インストール：

1. wget zipファイルへのリンク

2. 新しくダウンロードしたzipファイルを解凍します

3. cd / tmp / KingLazySHIELD

4. ./install.sh / var / tmp / KINGLAZY / SHIELDX-（your-script-name）/ home /（your-username）-force

上記のインストールコマンドが行うことは次のとおりです。

1. スクリプトの暗号化されたバージョンをディレクトリ/ var / tmp / KINGLAZY / SHIELDX-（your-script-name）にインストールします。

2. この暗号化されたスクリプトへのリンクは、/ home /（your-username）の代わりに指定したディレクトリに配置されます。これにより、絶対パスを入力しなくてもスクリプトに簡単にアクセスできます。

3. 誰もスクリプトを変更できないことを保証します-暗号化されたスクリプトを変更しようとすると、その操作が停止または削除されるまで、スクリプトは動作不能になります。誰かがそれ以外のスクリプトで何かを実行しようとするたびに通知するように設定することもできます。つまり、ハッキングや修正の試みです。

4. 誰も絶対にコピーできないようにします。誰もあなたのスクリプトを人里離れた場所にコピーして、それがどのように機能するかを見るためにそれをいじってみることはできません。スクリプトのすべてのコピーは、インストール中に指定した元の場所へのリンクである必要があります（ステップ4）。

注意：

これは、ユーザーに応答を促す対話型スクリプトでは機能しないと思います。値はスクリプトにハードコーディングする必要があります。暗号化により、誰も実際にこれらの値を見ることができないようになりますので、心配する必要はありません。

セキュリティを考慮しない別のソリューション（資格情報を別のファイルまたはデータベースに保存することをお勧めします）は、パスワードをgpgで暗号化し、スクリプトに挿入することです。

パスワードなしのgpgキーペアを使用して、USBに保管しています。（注：このキーペアをエクスポートするときは、-armorを使用しないで、バイナリ形式でエクスポートしてください）。

最初にパスワードを暗号化します：

echo -n "pAssw0rd" | gpg --armor --no-default-keyring --keyring /media/usb/key.pub --recipient someone@mail.com --encrypt

これにより、標準出力にgpg暗号化パスワードが出力されます。メッセージ全体をコピーして、これをスクリプトに追加します。

password=$(gpg --batch --quiet --no-default-keyring --secret-keyring /media/usb/key.priv --decrypt <<EOF 
-----BEGIN PGP MESSAGE-----

hQEMA0CjbyauRLJ8AQgAkZT5gK8TrdH6cZEy+Ufl0PObGZJ1YEbshacZb88RlRB9
h2z+s/Bso5HQxNd5tzkwulvhmoGu6K6hpMXM3mbYl07jHF4qr+oWijDkdjHBVcn5
0mkpYO1riUf0HXIYnvCZq/4k/ajGZRm8EdDy2JIWuwiidQ18irp07UUNO+AB9mq8
5VXUjUN3tLTexg4sLZDKFYGRi4fyVrYKGsi0i5AEHKwn5SmTb3f1pa5yXbv68eYE
lCVfy51rBbG87UTycZ3gFQjf1UkNVbp0WV+RPEM9JR7dgR+9I8bKCuKLFLnGaqvc
beA3A6eMpzXQqsAg6GGo3PW6fMHqe1ZCvidi6e4a/dJDAbHq0XWp93qcwygnWeQW
Ozr1hr5mCa+QkUSymxiUrRncRhyqSP0ok5j4rjwSJu9vmHTEUapiyQMQaEIF2e2S
/NIWGg==
=uriR
-----END PGP MESSAGE-----
EOF)

この方法では、USBがシステムにマウントされている場合にのみ、パスワードを復号化できます。もちろん、システムにキーをインポートする（安全性が低い、またはセキュリティがまったくない）ことも、パスワードで秘密キーを保護することもできます（そのため、自動化できません）。

#!/bin/bash
unset username
unset password
unset dbname
echo -n "username:"
read username
echo -n "dbname:"
read dbname
prompt="password:"

    while IFS= read -p "$prompt" -r -s -n 1 char
            do
                    if [[ $char == $'\0' ]]
                            then
                                    break
                    fi
                    prompt='*'
                    password+="$char"
            #       read -s -p "Enter Password: "  pswd
            #       echo -e "\nYour password is: " $pswd
            done

パスワードを保存する必要があるとは思わない。その理由を考えることはできません。むしろ、そのパスワードのソルトハッシュを保存する必要があります。元のパスワードが入力として渡されたときに、一部の関数によって確実に生成される文字列であり、passwordではありません。