Bir API anahtarı nasıl güvenle paylaşılır
Sırlarınızı açığa çıkarmadan
API anahtarları Slack, Teams, e-posta, iş kayıtları veya Git geçmişine ait değildir. Daha güvenli iş akışını öğrenin: anahtarın kapsamını daraltın, yerelde şifreleyin, tek kullanımlık bir bağlantı kullanın ve teslim bitince anahtarı değiştirin.
Önemli çıkarımlar
- API anahtarlarını e-postaya, sohbete, iş kayıtlarına, belgelere veya Git’e asla yapıştırmayın.
- En dar anahtarı kullanın: en az ayrıcalık, kısa ömür, iş bitince değiştirin.
- Sırları tarayıcıda şifrelenmiş tek kullanımlık bir bağlantıyla gönderin.
- Yüksek riskli anahtarlar için önce yerelde şifreleyin; yalnızca şifreli metni paylaşın.
- Paylaşımdan sonra olağandışı kullanımı izleyin — PrivateNote teslimdir, kasa değildir.
Bu sayfada
Her geliştirici eninde sonunda bir API anahtarını başkasına göndermek zorunda kalır — deneme ortamı erişimi, bir yüklenici, bir webhook bütünleştirmesi veya bir müşteri teslimi için. En hızlı yol genellikle en uzun izi bırakan yoldur.
API anahtarlarına üretim şifreleri gibi davranın
Bir API anahtarı, yazılım için fiilen bir şifredir. İzinlerine bağlı olarak sızan bir anahtar müşteri verisini açığa çıkarabilir, ücretli kaynakları tüketebilir, bulut altyapısı dağıtabilir, doğrulanmış alan adınız üzerinden e-posta gönderebilir veya bir yapay zeka faturasını şişirebilir.
İnsan şifrelerinin aksine API anahtarları çoğu zaman aylarca geçerli kalır, yapılandırma dosyalarının içinde durur ve çok faktörlü kimlik doğrulamayı tamamen atlar. Bir anahtar sızarsa bir saldırgan uygulamanız olarak çalışabilir ve kötü niyetli trafik, maliyetler sıçrayana veya veri zaten açığa çıkana kadar olağan üretim kullanımının içine karışabilir.
API anahtarlarını kalıcı sistemlere asla yapıştırmayın
Bu kanallar geçmişi korudukları için elverişlidir. Sırlar için yanlış yer olmalarının nedeni tam olarak budur.
- Slack, Microsoft Teams, Discord veya diğer sohbet geçmişi
- E-posta, SMS veya iletilmiş gelen kutusu dizileri
- Jira, Trello, Notion, Confluence veya GitHub sorunları
- Düz metin belgeler, elektronik tablolar ve paylaşılan bulut klasörleri
- Git commit’leri, çekme istekleri ve kod yorumları
API anahtarları gerçekte nerede sızar
Çoğu sızıntı karmaşık kriptografi kırılması değildir. Birisi, kayıt tutmak için kurulmuş bir sisteme bir sır kopyaladığında olur.
E-posta
E-posta uzun ömürlü kopyalar yaratır. Bir anahtar, iş bittikten çok sonra gelen kutularında, arşivlerde, yedeklerde, mobil eşitlemede, iletilmiş dizilerde ve arama dizinlerinde yaşayabilir.
Ekip sohbeti
Slack ve Teams bağlamı korur — sırlar için onları riskli kılan da budur. Yapıştırılmış bir anahtar, gelecekteki çalışma alanı üyeleri tarafından aranabilir veya ele geçirilmiş bir cihaz üzerinden sızabilir.
Proje araçları
Jira, Notion, Confluence, Trello ve GitHub Issues kimlik bilgisi kasaları değildir. Silinen kayıtlar dışa aktarımlarda, yedeklerde, denetim izlerinde ve yapay zeka destekli aramada hâlâ var olabilir.
Git depoları
Git geçmişi kalıcıdır. Bir anahtarı sonraki bir commit’te kaldırmak önceki commit’leri silmez. Herkese açık depolar sürekli taranır ve açığa çıkmış bulut kimlik bilgileri dakikalar içinde kötüye kullanılabilir.
Yüksek riskli anahtarlar: önce yerelde şifreleyin
Çoğu API anahtarı değiştirilebilir: deneme ortamı jetonları, kısa ömürlü bütünleştirme sırları ve değiştirmeyi planladığınız dar kapsamlı kimlik bilgileri. Bunlar için tarayıcıda şifrelenmiş tek kullanımlık teslim genellikle yeterlidir.
Bazı anahtarlar daha ağırdır — üretim yönetici erişimi, imzalama anahtarları, kök bulut kimlik bilgileri veya temiz biçimde iptal etmesi acı verici ya da olanaksız olan uzun ömürlü her şey. Onlara ana sırlar gibi davranın: herhangi bir web yüklemesinden önce yerelde şifreleyin, sonra şifreli metni PrivateNote üzerinden gönderin.
- age — dosya şifreleme için en yalın varsayılanlar (
age -p -o key.txt.age key.txt) - OpenSSL — bayrakları zaten biliyorsanız güvenilen CLI
- Şifreli dosyayı PrivateNote ile yükleyin; çözme parola ifadesini ayrı bir kanalda gönderin (Signal, telefon, yüz yüze)
Aynı iş akışı kripto para tohum ifadelerine ve yerine konamayan diğer ana sırlara da uygulanır. Tam age/OpenSSL anlatımı, parola ifadesi ipuçları ve tek kullanımlık bağlantıların ne zaman doğru araç olduğu — ve olmadığı — için kripto tohum ifadeleri ve tek kullanımlık bağlantılara bakın.
Daha güvenli bir teslim iş akışı
Bir insanın anahtara ihtiyacı olduğunda — bir uygulama onu çalışma anında almadığında — bu sırayı izleyin.
Anahtarın kapsamını belirleyin
Yalnızca asgari izinler
Yerelde şifreleyin
Anahtar tarayıcınızdan hiç çıkmaz
Bağlantıyı gönderin
Ham sırrı değil
İş bitince iptal edin
Teslimden sonra değiştirin
Herhangi bir not şifresini ayrı bir kanal üzerinden paylaşın — asla bağlantıyla aynı iletide değil.
PrivateNote teslime nasıl uyar
PrivateNote insandan insana an için kurulmuştur: kalıcı bir kayda dönüşmeden bir kişiye ulaşması gereken API anahtarları, SSH özel anahtarları, veritabanı kimlik bilgileri, kurtarma kodları, webhook imzalama sırları ve geçici şifreler.
Sır bir API kimlik bilgisi değil bir SSH anahtarıysa, açık ve özel anahtarlar, dağıtım anahtarları ve düzenleyici eklentileri için SSH anahtarlarının nasıl güvenle paylaşılacağına bakın.
Sır yüklemeden önce tarayıcınızda şifrelenir. PrivateNote düz metni değil şifreli metni saklar. Çözme anahtarı URL parçasında yaşar — # işaretinden sonraki bölüm — tarayıcılar sayfayı yüklerken bunu sunucuya göndermez. Bu, API kimlik bilgilerine uygulanmış tek kullanımlık gizli bağlantı modelidir.
https://privatenote.ai/note/abc123#kL8mN4...
- Sunucu not kimliğini ve şifreli yükü alır.
- Sunucu çözme anahtarını almaz.
- Okunduktan sonra yok olma ve süre sonu, şifreli notun ne kadar süre var olduğunu sınırlar.
PrivateNote özel sır depolarını tamamlar — bir Stripe anahtarını bir bütünleştirme ortağına göndermeniz, bir yükleniciyle geçici bir OpenAI anahtarı paylaşmanız veya bir ekip arkadaşına bir deneme ortamı kimlik bilgisine tek seferlik erişim vermeniz gerektiğinde aradaki boşluğu kapatır.
Sık sorulan sorular
Neden yalnızca bir ortam değişkeni kullanmayayım?
Ortam değişkenleri yerel yazılımı çalıştırmak için iyidir. Bu değeri bir ekip arkadaşına, yükleniciye, müşteriye veya bütünleştirme ortağına vermeniz gerektiğinde taşıma sorununu çözmezler.
API anahtarlarının süresi her zaman dolmalı mı?
Sağlayıcı desteklediğinde evet. Kısa ömürlü kimlik bilgileri, kazara ifşadan sonraki kötüye kullanım penceresini daraltır ve değiştirmeyi olağan iş akışının parçası yapar.
En güvenli iş akışı nedir?
Dar kapsamlı bir anahtar oluşturun, onu tarayıcıda şifrelenmiş tek kullanımlık bir bağlantıyla gönderin, isteğe bağlı şifreyi ayrı bir kanal üzerinden paylaşın, sonra görev bittiğinde anahtarı değiştirin veya iptal edin. Yüksek riskli veya uzun ömürlü anahtarlar için önce age veya OpenSSL ile yerelde şifreleyin ve yalnızca şifreli metni yükleyin.
PrivateNote bir sır yöneticisi midir?
Hayır. PrivateNote güvenli insandan insana teslimi çözer. Makineden makineye sır saklama için HashiCorp Vault, AWS Secrets Manager, Google Cloud Secret Manager veya Azure Key Vault kullanın.
Sonuç
Çoğu API anahtarı sızıntısı kriptografi başarısız olduğu için olmaz. Birisi kolaylık olsun diye bir sırrı kalıcı, aranabilir bir sisteme kopyaladığı için olur. Anahtarların kapsamını sıkı tutun, onları yalnızca gerektiğinde paylaşın ve sohbette, iş kayıtlarında, e-postada veya Git’te düz metin izi bırakmaktan kaçının. Teslim hattı tarafı için — .env commit’leri, CI günlükleri ve GitHub geçmişi — [CI/CD, .env dosyaları ve GitHub’daki sırlara](blog:secrets-in-cicd-env-github-leaks) bakın.
Bir API anahtarını sohbette bırakmadan paylaşın
Tarayıcıda şifrelenmiş, okunduktan sonra yok olan bir PrivateNote bağlantısı oluşturun. Tek kullanımlık notlar için hesap gerekmez.
Bir PrivateNote oluşturun ->
