Kasalar ve kimlik bilgileri

Kasalar, görevlerinizin oturum açarken kullandığı kullanıcı adlarını ve parolaları saklar: parolalar şifrelenir, hiç kimseye gösterilmez ve bir ajana yalnızca onlara ihtiyaç duyan bir görevi çalıştırırken verilir.

#Kasalar ve kimlik bilgileri

• Bir kasa, kimlik bilgilerini gruplar; örneğin Production veya Test systems.
• Bir kimlik bilgisi bir kasada bulunur ve bir Name, bir Username, bir Password ve bir Description değerine sahiptir. Görevler ona kasa adı ve kimlik bilgisi adıyla başvurur.

Kullanabileceğiniz kasaları görmek için Vaults'u açın. Bir kasanın kimlik bilgilerini, kullanıcı adları ve son güncellenme zamanlarıyla listelemek için soldan kasayı seçin. Parola sütunu her zaman nokta gösterir.

#Kasa ve kimlik bilgisi oluşturma

Kasaları ve kimlik bilgilerini yalnızca yöneticiler oluşturur ve değiştirir.

1. New vault'a tıklayın, bir ad ve açıklama girin ve kaydedin.
2. Kasayı seçin ve New credential'a tıklayın.
3. Name (görevler bunu kullanır; tırnak işaretlerine ve ters tırnaklara izin verilmez), Username, Password ve isteğe bağlı bir Description girin, ardından Create'e tıklayın.

Bir kimlik bilgisini değiştirmek için menüsünü açın ve Edit or replace password'ü seçin. Kayıtlı parolayı korumak için Password alanını boş bırakın. Kasanın kendi menüsü Rename or describe ve Delete vault seçeneklerini sunar.

Uyarı: Bir kasayı silmek tüm kimlik bilgilerini siler. Bir kimlik bilgisini silmek veya onu ya da kasasını yeniden adlandırmak, onu kullanan görevlerin siz güncelleyene kadar başarısız olmasına yol açar.

#Bir kasayı kimler kullanabilir

Erişim izni vermek için kasayı seçin ve Access'e tıklayın (yalnızca Manage vaults). Access to kasa çekmecesinde Add role or user'a tıklayın, bir rol veya kullanıcı seçin ve Use işaretli kalsın, ardından Save'e tıklayın. Boş bir liste, kasayı yalnızca Manage vaults veya Use every vault yetkisine sahip kullanıcıların kullanabileceği anlamına gelir. Birden fazla rolü olan bir kullanıcı, bu rollerden herhangi birine izin verilen kasaları kullanabilir.

Bir erişim izni her zaman kullanım anlamına gelir: o rol veya kullanıcı tarafından başlatılan görevler kasanın kimlik bilgilerini okuyabilir. Bir yönetici dışında hiç kimse kimlik bilgisi ekleyemez, değiştiremez veya silemez ve hiç kimse kayıtlı bir parolayı görüntüleyemez.

#Bir görevde kimlik bilgisi kullanma

Bir kimlik bilgisini set --type:credential ile bir değişkene okuyun, ardından Username ve Password özelliklerini kullanın:

set --name:erp --type:credential --vault:"Production" --credential:"ERP Bot"
browser --action:open --url:"https://erp.example.com/login" --output:web
capture --browser:$web$ --action:settext --dompath:"//input[@id='user']" --value:$erp.Username$
capture --browser:$web$ --action:settext --dompath:"//input[@id='password']" --value:$erp.Password$
capture --browser:$web$ --action:click --dompath:"//button[@type='submit']"

Özellikler panelinde vault ve credential alanları, kullanabileceğiniz kasaları ve kimlik bilgilerini içeren seçiciler sunar.

İpucu: Vaults sayfasında, bir kimlik bilgisinin yanındaki kopyalama düğmesi ilgili set --type:credential satırını panoya kopyalar.

mail gibi bir kimlik bilgisi değişkeni alan komutlar onu doğrudan kabul eder, örneğin --credential:$mailbox$.

#E-posta hesapları

mail komutu hesabını kendisi sorar: özellikler panelinde vault ve credential alanlarından kasayı ve kimlik bilgisini seçin (bu alanlar zorunlu alanlarla birlikte gösterilir); komut o kimlik bilgisinin kullanıcı adı ve parolasıyla oturum açar. Ayrı bir set satırı gerekmez ve parola görevde hiçbir zaman görünmez:

mail --action:send --smtp:"smtp.gmail.com" --port:587 --vault:"Mail" --credential:"Robot mailbox" --from:"robot@company.com" --to:"team@company.com" --subject:"Report" --body:"The report is attached" --attachment:"C:\Reports\daily.pdf"
mail --action:read --server:"imap.gmail.com" --vault:"Mail" --credential:"Robot mailbox" --subject:"Invoice" --output:messages

Kimlik bilgisinin kullanıcı adı olarak e-posta adresini (veya hesabın kullanıcı adını) kaydedin. Gmail, Outlook.com ve Yahoo, programlardan gelen normal parolayı kabul etmez: hesapta iki adımlı doğrulamayı açın ve bunun yerine bir uygulama parolası kaydedin. Parolayla oturum açmanın kapalı olduğu Microsoft 365 posta kutuları, bir uygulama kaydıyla --authtype:oauth2 kullanır; bkz. mail. Oturum açmadan posta kabul eden bir aktarma (relay) sunucusu kimlik bilgisi gerektirmez (--authtype:none).

Sunucu oturum açmayı reddederse hata bunu söyler ve komut --retry ile tekrarlanmaz, çünkü art arda başarısız denemeler hesabı kilitleyebilir.

#E-postalar üzerinde döngü

E-postaları tek tek işlemek için mail türünde bir loop kullanın (komut paletinde Loop · Mail; Ctrl+K içinde "email loop" yazabilirsiniz). Döngü, mail --action:read ile aynı hesabı, klasörü ve filtreleri alır — kasa ve kimlik bilgisi seçicileri, sunucu önerileri, okunmamış, gönderen, alıcı, konu, metin, şu tarihten itibaren, şu tarihten önce, ekli ve en fazla — ve komutlarını eşleşen her ileti için bir kez, en yeniden başlayarak çalıştırır. Döngü değişkeni o anki iletidir: Id, From, FromName, To, Cc, Subject, Date, Body, HtmlBody, IsRead ve Attachments alanlarına sahip bir kayıt (değişken seçici bunları $msg.Subject$ gibi sunar). Döngünün içinde, tek bir ileti üzerinde çalışan mail eylemlerine --id:$msg.Id$ verin:

loop --type:mail --server:"imap.gmail.com" --vault:"Mail" --credential:"Robot mailbox" --unread:true --subject:"Invoice" --hasattachments:true --variable:msg --index:i
    log --message:"$i$: $msg.Subject$ from $msg.FromName$"
    mail --action:saveattachments --server:"imap.gmail.com" --vault:"Mail" --credential:"Robot mailbox" --id:$msg.Id$ --destination:"C:\Invoices" --filter:"*.pdf"
    mail --action:move --server:"imap.gmail.com" --vault:"Mail" --credential:"Robot mailbox" --id:$msg.Id$ --target:"Processed"
endloop

• İletiler döngü başladığında bir kez okunur (en fazla --max, varsayılan 50); döngü çalışırken gelen iletiler bir sonraki çalıştırmayı bekler.
• --markread:true, okunan iletilerin tümünü okunur okunmaz, ilk turdan önce okundu olarak işaretler. Bir iletiyi ancak işlendikten sonra okundu yapmak için --markread ayarını kapalı bırakın ve turu mail --action:markread --id:$msg.Id$ ile bitirin: böylece turu başarısız olan ileti okunmamış kalır ve bir sonraki çalıştırmada yeniden ele alınır.
• Hesap, klasör veya filtreler hatalıysa hata, günlük satırları ve hata ayıklayıcı gibi döngünün satırını gösterir (döngüdeki bir kesme noktası orada iki kez durur: iletiler okunmadan önce ve ilk turdan önce).
• mail --action:read çalıştırabilen her ajan bu döngüyü çalıştırır; yalnızca --index güncel ajanı gerektirir.

#Parola ne zaman okunur

Ajan, set --type:credential komutu çalıştığında kimlik bilgisini sunucudan ister. Sunucu onu yalnızca şu koşullarda teslim eder:

• ajan o çalıştırmayı yürütüyor ve çalıştırma devam ediyorsa ve
• çalıştırmayı başlatan kullanıcı kasayı kullanabiliyorsa. Zamanlanmış bir çalıştırma için bu, zamanlamayı oluşturan kullanıcıdır.

Aksi takdirde komut, The user who started the execution has no access to vault 'Production' gibi bir mesajla başarısız olur.

#CyberArk

Kurumunuz parolalarını CyberArk'ta tutuyorsa bir CyberArk kasası oluşturun: bu kasadaki kimlik bilgileri parola saklamaz, yalnızca CyberArk'ın hesabı nerede bulacağını saklar. Bir görev böyle bir kimlik bilgisini her okuduğunda Botream sunucusu parolayı CyberArk Central Credential Provider'dan (CCP, AIMWebService REST API'si) alır ve görevi çalıştıran ajana, tıpkı bir Botream kimlik bilgisinde olduğu gibi teslim eder. Ajanlar CyberArk'a hiç bağlanmaz ve Botream CyberArk parolalarını önbelleğe almaz: her okuma CyberArk'a yeniden sorar, böylece değiştirilen (rotate edilen) bir parola hemen kullanılır.

Görevler değişmez: set --type:credential --vault:"CyberArk ERP" --credential:"ERP Bot" ve mail komutunun vault ve credential alanları iki kasa türünde de aynı çalışır; erişim izinleri de aynıdır.

#CyberArk'ta neler ayarlanır

CyberArk yöneticinizden şunları isteyin:

1. Bir uygulama (PVWA'da Applications), örneğin Botream. Botream'in gönderdiği değer bu uygulamanın Application ID'sidir.
2. Uygulama için kimlik doğrulama:
   • Allowed machines: Botream sunucusunun adresi (ajanlar değil: CyberArk'ı yalnızca sunucu çağırır).
   • Sertifika ile kimlik doğrulama (önerilir): Botream sunucusu için verilmiş, özel anahtarı ve parolasıyla birlikte PFX (.pfx/.p12) dosyası olarak size iletilen bir istemci sertifikası. Diğer yöntemler (işletim sistemi kullanıcısı, yol, hash) uygulanmaz, çünkü Botream web servisini ağ üzerinden çağırır.
3. Safe yetkileri: uygulama ve CCP'nin Credential Provider kullanıcısı (genellikle Prov_<sunucu>), Botream'in okuduğu her safe'in üyesi olmalı; Retrieve accounts yetkisiyle (sorgu kullanmak için List accounts de).
4. Central Credential Provider web servisinin adresi, örneğin https://ccp.company.local. Web servisi istemci sertifikası istiyorsa (IIS'te Require SSL ve istemci sertifikaları), kullanılacak sertifika yukarıdaki PFX'tir.

#CyberArk kasası oluşturma

1. New vault'a tıklayın, Where the passwords are kept altında CyberArk'ı seçin ve bir ad girin.
2. Central Credential Provider address: temel adres, örneğin https://ccp.company.local. Botream sonuna /AIMWebService/api/Accounts ekler.
3. Application ID: CyberArk'ta tanımlandığı gibi.
4. Client certificate: Upload certificate'e tıklayın, PFX dosyasını seçin ve parolasını girin. Kaydettikten sonra form yalnızca sertifikanın konusunu ve son geçerlilik tarihini gösterir (örneğin Installed: CN=botream-server · expires 12.10.2027); dosya ve parolası bir daha asla gösterilmez. Değiştirmek için Replace certificate veya Remove'u kullanın.
5. Verify the TLS certificate açık kalsın. Sağlayıcının sertifikası kurum içi bir CA'dan geliyorsa, o CA'nın sertifikasını (PEM) CA certificate alanına yapıştırın veya Load from file'a tıklayın (.pem, .crt veya .cer). Doğrulamayı yalnızca bir test sistemi için kapatın.
6. Timeout (seconds) (varsayılan 30), Botream'in bir yanıtı ne kadar bekleyeceğini sınırlar. Vault connection timeout, CCP'nin ConnectionTimeout değeridir (sağlayıcının CyberArk Vault'u ne kadar bekleyeceği); sağlayıcının varsayılanı için boş bırakın.
7. Test connection altında uygulamanın okuyabildiği bir Safe ve Object (hesap adı) girin ve Test connection'a tıklayın. Başarılı olursa OK: CyberArk returned the account of user svc_rpa gibi bir sonuç görürsünüz; parola asla gösterilmez.

Kasa listesi, CyberArk kasalarının yanında bir CyberArk etiketi gösterir. Bir kasanın türü yalnızca kasada kimlik bilgisi yokken değiştirilebilir.

#CyberArk kimlik bilgisi ekleme

CyberArk kasasını seçin, New credential'a tıklayın ve şunları girin:

• Name: görevlerin kullandığı ad.
• How CyberArk finds the account: Safe and object (Safe, Object — hesabın CyberArk'taki adı — ve isteğe bağlı olarak Folder, varsayılanı Root) veya CCP sorgu sözdizimiyle Query, örneğin Safe=RPA;UserName=svc_rpa.
• Username (isteğe bağlı): CyberArk'ın döndürdüğü kullanıcı adını kullanmak için boş bırakın; her zaman aynı kullanıcı adını kullanmak için doldurun.

Hesabı almak için Test'e tıklayın: sonuç kullanıcı adıyla birlikte OK gösterir, parolayı asla göstermez. Kimlik bilgisi listesi, parola noktaları yerine her hesabın CyberArk'taki yerini gösterir.

#CyberArk reddettiğinde

Sunucu, istemci sertifikasıyla ve CyberArk denetim kaydında görünen Botream execution 1234 gibi bir Reason ile GET {adres}/AIMWebService/api/Accounts?AppID=…&Safe=…&Folder=…&Object=… (veya &Query=…) çağrısını yapar. CyberArk parolayı döndürmezse set komutu (veya mail komutu) nedenini söyleyen bir mesajla başarısız olur; test düğmeleri de aynısını gösterir:

#Güvenlik

• İstemci sertifikası ve parolası dahil bağlantı ayarları, Botream parolaları gibi şifreli (AES-256-GCM) saklanır; sertifikanın yalnızca konusu ve son geçerlilik tarihi gösterilir.
• CyberArk parolaları Botream'de saklanmaz ve önbelleğe alınmaz; sunucuda yalnızca ajana teslim edilirken bulunur.
• Her okuma denetlenir (sağlayıcıyla birlikte Credential access veya nedeniyle birlikte Credential access failed), her test de öyle (Vault connection test, Credential test) — hiçbirinde parola yer almaz.
• Ajan, CyberArk parolalarını da diğer kimlik bilgileri gibi günlüklerde maskeler.

#Parolalar nasıl korunur

• Bekleme sırasında şifrelenir: AES-256-GCM ile. Anahtar kurulum sırasında sunucuda belirlenir; sunucuyla birlikte yedekleyin, çünkü kayıtlı parolalar o olmadan okunamaz. Bkz. Yükseltme ve yedekleme.
• Asla gösterilmez: hiçbir sayfa ve hiçbir API bir parolayı döndürmez, yöneticilere bile. Bir parola yalnızca değiştirilebilir.
• Günlüklerde maskelenir: ajan, okuduğu her parolayı günlük satırlarında, hata mesajlarında, catch'in hata değişkeninde ve görev çıktılarında *** ile değiştirir. Hata ayrıntılarında ve hata ayıklayıcıda gösterilen değişkenler de maskelenir.
• Yalnızca çalışırken gönderilir: ajanlar bir parolayı yalnızca onu isteyen çalıştırma sırasında alır.

Not: Kimlik bilgilerinin ağda hiçbir zaman düz metin olarak dolaşmaması için üretim ortamında sunucu, tarayıcılar ve ajanlar arasında HTTPS kullanın. Bkz. Sunucuyu kurma.

#Denetim

Her kasa ve kimlik bilgisi değişikliği, her erişim izni değişikliği ve bir kimlik bilgisini okumaya yönelik her girişim, parola olmadan denetim kaydına işlenir: