Kabuk komut dosyalarındaki bir şifreyi nasıl gizleyebilirim? Veritabanına erişen çok sayıda komut dosyası var. Senaryoyu açarsak diğerleri de kullanıcı adı ve şifreyi bilir. Birisi nasıl saklanacağını bilen varsa lütfen bana bildirin.
Tek bir yolum var: şifreyi bir dosyaya yerleştirin ve dosyayı gizli yapın ve dosyaya erişecek kimse yok (izinleri değiştirin ve veritabanına erişirken dosyayı komut dosyasında kullanın).
Yanıtlar:
İlk olarak , birkaç kişinin daha önce de söylediği gibi, kimlik bilgilerini senaryodan ayrı tutmak önemlidir. (Artırılmış güvenliğe ek olarak, aynı komut dosyasını farklı kimlik bilgileri olan birkaç sistemde yeniden kullanabileceğiniz anlamına gelir.)
İkincisi , yalnızca kimlik bilgilerinin güvenliğini değil, aynı zamanda bu kimlik bilgilerinin tehlikeye atılması durumunda da etkisini göz önünde bulundurmalısınız. Veritabanına tüm erişim için tek bir şifreniz olmamalı, farklı erişim seviyelerinde farklı kimlik bilgilerine sahip olmalısınız. Örneğin, veritabanında arama yapabilme yeteneğine sahip bir DB kullanıcısına sahip olabilirsiniz - bu kullanıcının salt okunur erişime sahip olması gerekir. Başka bir kullanıcı yeni kayıt ekleme iznine sahip olabilir, ancak silme hakkına sahip olmayabilir. Üçüncüsü, kayıtları silme iznine sahip olabilir.
Her bir hesap için izinleri kısıtlamanın yanı sıra, her bir hesabın kullanılabileceği yerle ilgili bir kısıtlama da olmalıdır. Örneğin, web sunucunuz tarafından kullanılan hesabın, web sunucusundan başka bir IP adresinden bağlanmasına izin verilmemelidir. Veritabanına tam kök izinleri olan bir hesap, nereden bağlanabileceği açısından gerçekten çok kısıtlanmalı ve etkileşimli olarak asla kullanılmamalıdır. Ayrıca, her hesapta yapılabilecekleri tam olarak sınırlamak için veritabanında saklı yordamları kullanmayı düşünün.
Bu kısıtlamaların sistemin DB-sunucu tarafında uygulanması gerekir, böylece müşteri tarafı tehlikeye girse bile kısıtlamalar ondan değiştirilemez. (Ve tabii ki, DB sunucusunun DB konfigürasyonuna ek olarak güvenlik duvarları vb. İle de korunması gerekiyor.)
Yalnızca sınırlı salt okunur erişime izin verilen ve yalnızca belirli bir IP adresinden izin verilen bir DB hesabı söz konusu olduğunda, verilerin hassasiyetine ve betiğin ana bilgisayarının güvenliğine bağlı olarak, bundan daha fazla kimlik bilgilerine ihtiyacınız olmayabilir. kaçıyor. Bir örnek, web sitenizde, yalnızca web sayfasında sunulacak bilgileri ayıklayan saklı bir yordam kullanmasına izin verilen bir kullanıcıyla çalıştırılabilecek bir arama formu olabilir. Bu durumda, bir şifre eklemek gerçekten fazladan bir güvenlik sağlamaz, çünkü bu bilgi zaten herkese açıktır ve kullanıcı daha hassas olabilecek başka verilere erişemez.
Ayrıca, veri tabanı bağlantısının TLS kullanılarak yapıldığından emin olun, aksi takdirde ağı dinleyen herhangi biri kimlik bilgilerinizi alabilir.
Üçüncüsü , ne tür bilgiler kullanacağınızı düşünün. Şifreler sadece bir formdur ve en güvenli değildir. Bunun yerine, bir tür kamu / özel anahtar çifti veya AD / PAM veya benzerini kullanabilirsiniz.
Dördüncüsü , betiğin çalışacağı koşulları göz önünde bulundurun:
Etkileşimli olarak çalıştırılıyorsa, şifreyi veya şifreyi özel anahtarın veya özel anahtarın içine girmeli veya geçerli bir Kerberos bileti ile giriş yapmış olmalısınız, çalıştırdığınızda - başka bir deyişle, komut dosyası Bir dosyadan okumak yerine, siz çalıştırdığınız sırada doğrudan sizden kimlik bilgileri alabilirsiniz.
Bir web sunucusundan çalıştırılıyorsa, web sunucusunu başlattığınız sırada kimlik bilgilerini ayarlamayı düşünün. Buradaki en iyi örnek SSL sertifikaları - genel bir sertifikaya ve özel bir anahtara sahipler ve özel anahtara bir şifre giriyor. Özel anahtarı web sunucusunda saklayabilirsiniz, ancak Apache'yi başlattığınızda şifreyi girmeniz gerekir. Sunucu başlatıldıktan sonra çıkarılabilecek veya kilitlenebilecek bir fiziksel kart veya HSM gibi bir tür donanım hakkında da bilgi sahibi olabilirsiniz. (Tabii ki, bu yöntemin dezavantajı, bir şey olursa sunucunun kendi başına yeniden başlatılamamasıdır. Bunu, sistemimin tehlikeye atması riskine tercih ederim, ancak kilometreniz değişebilir ...)
Senaryo cron'dan çalıştırılıyorsa, zor kısım budur. Sisteminizde herhangi birisinin birisinin onlara erişebileceği herhangi bir yerde yalan söylemesini istemezsiniz - ancak betiğinizin onlara erişebilmesi için etrafta yattığını mı istiyorsunuz? Pekala, doğru değil. Komut dosyasının ne yaptığını tam olarak düşünün. Veritabanında hangi izinlere ihtiyaç duyuyor? Yanlış kişinin bu izinlerle bağlantısı olup olmaması önemli değil, böylece kısıtlanabilir mi? Bunun yerine komut dosyasını doğrudan, başkalarının erişimine sahip olan sunucu yerine, başkalarının erişemediği DB sunucularında çalıştırabilir misiniz? Aklıma olamayacağını nedense, kesinlikle olursa gerekir güvensiz bir sunucuda komut çalışan var ve olmalı tehlikeli / yıkıcı bir şey yapabilmek ... şimdi mimarinizi yeniden düşünmek için iyi bir zaman.
Beşinci olarak , veritabanınızın güvenliğini önemsiyorsanız , bu komut dosyalarını diğer kişilerin erişebildiği sunucularda çalıştırmamanız gerekir. Birisi sisteminizde kaydedilir, sonra onlar olacaktır kimlik bilgilerinizi almak imkanı vardır. Örneğin, bir SSL sertifikasına sahip bir web sunucusu durumunda, en azından birinin kök kazanması ve httpd işleminin bellek alanına erişmesi ve kimlik bilgilerini çıkarması için teorik bir olasılık vardır. Son zamanlarda SSL üzerinden yapılabilecek en az bir istismar oldu, saldırganın giriş yapmasını gerektirmiyordu.
Ayrıca, hangi kullanıcıların ne yapabileceğini sınırlamak için SELinux veya apparmor veya sisteminiz için ne varsa kullanılabilir. Kimlik bilgilerine erişmeyi başarabilseler bile, kullanıcıların veritabanına bağlanmaya bile çalışmalarına izin vermemenizi sağlar.
Eğer bütün bunlar size fazla mazeret gibi geliyorsa ve bunu göze alamazsanız veya yapacak vaktiniz yoksa - o zaman (kibirli ve elitist) görüşüme göre, veritabanınızda önemli veya hassas bir şey saklamamalısınız. Ve önemli veya hassas bir şeyi saklamıyorsanız, kimlik bilgilerinizi sakladığınız yer de önemli değildir - bu durumda neden bir şifre kullanmalısınız?
Son olarak kesinlikle kimlik çeşit depolamak kaçının olamazsa, bunun için (a komut dosyası tarafından bunu istendiğinde betiğinize gerektiğini, çünkü kimlik bilgileri bir derece geçici olarak sahipliğini bağışta bulunabileceğini salt okunur ve kökü ve kök ait olabilir değil olacak kesinlikle gerekli olmadıkça root olarak çalıştırın ve bir veritabanına bağlanmak onu zorunlu kılmaz). Ama yine de iyi bir fikir değil.
Her şeyden önce, herhangi bir şekilde bir şifreyi içeride ya da yanında bir şifreyi saklamaktan kaçınmak için bazı şeyleri değiştirebilirseniz, bunu yapmak için her türlü çabayı göstermelisiniz. Jenny D'nin cevabı bu etki için birçok iyi tavsiye içeriyor.
Aksi takdirde, şifreyi sınırlı izinlere sahip ayrı bir dosyaya yerleştirme fikriniz oldukça fazladır. Örneğin bu dosyayı ana komut dosyasından alabilirsiniz:
. /usr/local/etc/secret-password-hereAyrıca, ana betiğin izinlerini yalnızca yetkili kişilerin yürütmesine izin verecek şekilde kısıtlayabilirsiniz, ancak yalnızca parolanın kendisini sınırlı bir dosyada önerip saklamanız daha iyi olur. Bu şekilde, kodun incelenmesine (hassas sırlar olmadan), sürüm kontrolüne ve komut dosyası çevresinde daha kolay kopyalanmasına vb. İzin verebilirsiniz.
/usr/local/etcsembolik bir bağlantı olabilir " dediğini görüyorum /etc/local. Onu özledim. Yani haklısın, ama bu bir MAY, yani isteğe bağlı. Ama evet, önemli değil ve kişisel tercih.
/etc//usr/local/
Diğer cevaplar bunun nasıl olduğunu ele aldı , ancak olup olmadığını düşüneceğim . Kullanıcılarınızın ne tür bir veritabanına bağlandığına bağlı olarak, bu istemci programları tarafından zaten kullanılmış olan uygun bir mekanizmaya zaten sahip olabilirsiniz, bu durumda bunları kullandığınızdan emin olun (düşünüyorum ~/.mysqlrcya da ~/.pgpass).
Birkaç kullanıcıya, paylaşılan bir hesap kullanarak belirli sorgular yapmak için veritabanına erişme olanağı veriyorsanız, muhtemelen yapmamalısınız. Bunun yerine, veritabanında hesapları olduğundan ve bu hesapların gerekenden daha fazla izne sahip olmadığından emin olun (büyük olasılıkla çoğunu okuyun ve çok az yazma erişimi). Bazı tablolarda, aksi takdirde erişemedikleri belirli sorgular yapmaları gerekiyorsa, bunu yapmalarını sağlamak için saklı yordamlar sağlayın SECURTY DEFINER.
Eğer mağaza kimlik gerek yukarıdaki kaçınır hiçbiri varsa, o zaman burada başka cevapları okuyun.
Şifreyi erişilemez bir yerde gizleme fikriniz koşullara bağlı olarak iyi olabilir.
Eğer bilgi ayrı ise, dosyanın basit bir şekilde düzenlenmesi, örneğin bir meslektaşın kod incelemesi sırasında gösterilmeyecektir. Ancak hesabınıza erişimi olan herhangi birisinin kolayca bu tür bir dosyayı bulabileceğini anlayın. Bu ~/.sshtür amaçlar için bir alt dizini kullandım ssh, erişim haklarının ~/.sshyeteri kadar kısıtlanmamasından şikayetçi olan basit bir sebepten dolayı .
Bununla birlikte, kullanıcı adı ve / veya şifrelerin bu şekilde görünmesini önlemek için yapabileceğiniz başka şeyler vardır.
Şaşırtma : Bir betiği düzenlerken kullanıcı adını veya şifreyi kimsenin okumasını istemiyorsanız, metni metnin içine yazabilirsiniz ancak düz metin olarak değil, gizlenmiş olarak bırakabilirsiniz. Eğer şaşkın sürüm, kendisine bakan biri tarafından ezberlenmesini önleyecek kadar uzunsa, şifre çözme yöntemi ve anahtarın açık görüşlülüğü bile olsa, bu bilinemez. Elbette bu, hesabınıza erişimi olan bir kişi tarafından önemsiz şekilde engellenecektir.
GPG'yi kullanma :
Biraz daha iyi, ancak sisteminizdeki kök kullanıcının saldırılarına karşı tam kanıtı değil, kullanıcı adınızı / şifrenizdeki çiftleri gpghalka açık bir dosyada şifrelemek ve komut dosyasının dosyadaki içeriği almasını sağlamak (eğer sizden bir şifre istenebilir) önbelleğe /) sona erdi. Dizüstü bilgisayarımı etrafımda bıraktığımda ancak kartı çıkardığımda, pim hala önbelleğe alınsa bile erişim mümkün olmadığından ggp kartı kullanıyorum. En azından birkaç dakikada 20 kez bir şey yaparsam pimi sadece bir kez vermem gerekiyor.
Güvenlik her zaman kolaylık ile ters orantılı görünmektedir (kurulum ve kullanım).
Parolaları bir bash betiğinde saklamanın bir yolu var, ancak betiği şifrelemek ve gizlemek zorundasınız, böylece hiç kimse tam olarak ne yaptığını görmek için onu gerçekten okuyamaz veya hata ayıklayıcıyı çalıştıramaz. Bir bash / shell betiğini şifrelemek ve şaşırtmak ve gerçekten çalıştırılabilir olmasını sağlamak için, buraya kopyalayıp yapıştırmayı deneyin:
http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm
Yukarıdaki sayfada yapmanız gereken tek şey betiğinizi göndermek (huzurunuz için önce örnek bir betiği gönderebilirsiniz). Sizin için bir zip dosyası oluşturulur. İndirme bağlantısına sağ tıklayın ve sağladığınız URL'yi kopyalayın. Ardından, UNIX kutunuza gidin ve aşağıdaki adımları izleyin.
Kurulum:
zip-link-zip dosyasına yaz
yeni indirilen zip dosyasını aç
cd / tmp / KingLazySHIELD
./install.sh / var / tmp / KINGLAZY / SHIELDX- (betiğinizin adı) / ana sayfa / (kullanıcı adınız)
Yukarıdaki yükleme komutunun sizin için yapacağı şey:
Komut dosyanızın şifrelenmiş sürümünü / var / tmp / KINGLAZY / SHIELDX- (komut dosyanızın adı) dizinine yükler.
Bu şifreli betiğin linkini, / home / (kullanıcı adınız) yerine hangi dizinde belirttiğinize yerleştirir - bu şekilde, betiğe mutlak yolu yazmanıza gerek kalmadan kolayca erişmenizi sağlar.
NO ONE'un betiği değiştirebildiğinden emin olun - Şifreli betiği değiştirme girişimleri, bu girişimler durdurulana veya kaldırılana kadar çalışamaz duruma getirir. Hatta biri komut dosyasıyla çalıştırma dışında herhangi bir şey yapmaya çalıştığında sizi bilgilendirmek için bile yapılandırılabilir ... yani hackleme veya değiştirme girişimleri.
Kesinlikle hiç kimsenin kopyalarını çıkarmamasını sağlar. Hiç kimse komut dosyanızı tenha bir konuma kopyalayamaz ve nasıl çalıştığını görmek için onunla uğraşmaya çalışamaz. Komut dosyasının tüm kopyaları, yükleme sırasında belirttiğiniz orijinal konuma bağlantılar olmalıdır (4. adım).
NOT:
Bunun, kullanıcıdan bir yanıt almasını isteyen etkileşimli komut dosyaları için işe yaradığını sanmıyorum. Değerler komut dosyasına sabit olarak kodlanmalıdır. Şifreleme, hiç kimsenin bu değerleri görememesini sağlar, bu yüzden endişelenmenize gerek yoktur.
Güvenlikten bağımsız olarak başka bir çözüm de (Kimlik bilgilerini başka bir dosyada veya bir veritabanında tutmanın daha iyi olacağını düşünüyorum) şifreyi gpg ile şifrelemek ve komut dosyasına eklemek.
USB'de tuttuğum şifresiz bir gpg anahtar çifti kullanıyorum. (Not: Bu anahtar çiftini dışa aktardığınızda --armor kullanmayın, bunları ikili biçimde dışa aktarın).
İlk önce şifrenizi şifreleyin:
echo -n "pAssw0rd" | gpg --armor --no-default-keyring --keyring /media/usb/key.pub --recipient someone@mail.com --encryptBu standart çıktıda gpg şifreli şifreyi basacaktır. Mesajın tamamını kopyalayın ve bunu komut dosyasına ekleyin:
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)Bu şekilde, yalnızca sisteme usb bağlanırsa, şifrenin şifresi çözülebilir. Elbette, anahtarları sisteme aktarabilirsiniz (daha az güvenli veya hiç güvenlik yok) veya özel anahtarı parola ile koruyabilirsiniz (böylece otomatik hale getirilemez).
#!/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Şifreyi saklaman gerektiğine inanmıyorum. Bunun için tek bir iyi sebep düşünemiyorum. Aksine, bu parolanın tuzlu bir karmasını saklamalısınız - orijinal parola giriş olarak iletildiğinde bazı işlevler tarafından güvenilir bir şekilde üretilen, ancak parola asla kullanılmayan bir dize .