Environment variable-ები და საიდუმლოებები აპლიკაციის სერვერზე

credential-ის გაჟონვის ყველაზე გავრცელებული გზა თავდასხმა არ არის. ეს არის რეპოზიტორია, რომელიც კერძო იყო, როცა გასაღები შევიდა, და საჯარო, როცა ვიღაცამ fork გააკეთა, და მაშინ გასაღები ისტორიაშია და არა ფაილში, სადაც ხაზის წაშლა არაფერს არ აკეთებს. მეორე ყველაზე გავრცელებული გზა ლოგის ხაზია, რომელმაც გაშვებისას მთელი კონფიგურაციის ობიექტი დაბეჭდა. არცერთი მათგანი ჭკვიანური არ არის და ორივეს ერთი ჩვევა ერიდება: მნიშვნელობა სერვერზე ცხოვრობს და არა იმაში, რასაც push-ავ.

ამ ჩვევის უკან მექანიზმია და მექანიზმს მკვეთრი კიდეები აქვს. Environment variable-ები საცავი არ არის - მათ კითხულობს პროცესი, ყველაფერი, რასაც ის ქმნის, და ყველა, ვისაც წვდომა აქვს ჩანართზე, რომელიც მათ აყენებს. ეს პოსტი გვიჩვენებს, რა არის ისინი სინამდვილეში, როგორ დააყენო და წაიკითხო გამოცნობის გარეშე, ზუსტად რა უნდა გააკეთო, როცა ერთი უკვე დაკომიტდა, და ხუთ ადგილს, სადაც ისინი გაჟონავს, მაშინაც კი, როცა ყველაფერი დანარჩენი სწორად გააკეთე.

რა არის environment variable სინამდვილეში#

Unix სისტემაზე ყოველი პროცესი იწყება ორი რამით, რომელსაც მას ის გადასცემს, ვინც გაუშვა: არგუმენტებით და გარემოთი. გარემო არის NAME=value წყვილების უბრალო სია. შენი პროგრამა მას სტანდარტული ფუნქციით კითხულობს და ყოველი შვილობილი პროცესი, რომელსაც ქმნის, ასლს მემკვიდრეობით იღებს.

ოთხი თვისება გამომდინარეობს აქედან და ოთხივე მნიშვნელოვანია:

• ისინი string-ებია. არ არსებობს რიცხვები, boolean-ები და null-ები. DEBUG=false არის შვიდსიმბოლოიანი string false, რომელიც უმეტეს ენაში truthy-ა, თუ პირდაპირ შეამოწმებ. პარსინგი შეგნებულად გააკეთე.
• ისინი პროცესის დაწყებამდე დგება. ერთის შეცვლა Startup ჩანართზე არაფერს აკეთებს, სანამ არ გადატვირთავ. ეს გაკვირვებს ხალხს, რომელიც კონფიგურაციის reload-ს ელის.
• ისინი მემკვიდრეობითია. shell სკრიპტი, რომელიც შენს აპს უშვებს, მათ გადასცემს. ასევე subprocess, რომელსაც სურათის გადასაყვანად უშვებ. თუ dependency რაღაცას shell-ით უშვებს, ის რაღაც შენს ბაზის პაროლს ხედავს.
• ისინი დაშიფრული არ არის. ისინი პროცესის მეხსიერებაში ინახება და Linux-ზე /proc-ში ყველაფრისთვის, რაც იმავე მომხმარებლით მუშაობს. მათი ღირებულება ისაა, რომ შენი წყაროს ხისა და ლოგების გარეთ რჩება და არა ისაა, რომ ყუთში არის დაკეტილი.

ალტერნატივა, რომელსაც უმეტესობა ირჩევს, კონფიგურაციის ფაილია რეპოზიტორიაში, რომელიც ზუსტად ზემოთ აღწერილი გზით ჩავარდება, ან კონფიგურაციის ფაილი რეპოზიტორიის გარეთ, რაც კარგია და დაახლოებით ის არის, რაც .env ფაილია. გარემო უბრალოდ ფაილს განტოლებიდან იღებს.

მათი დაყენება: Startup ჩანართი და .env ფაილები#

პანელზე დაფუძნებულ ჰოსტზე Startup ჩანართი სერვერის ცვლადებს ატარებს. დააყენე სახელი და მნიშვნელობა, გადატვირთე და შენი აპლიკაცია მას ისე კითხულობს, როგორც უკვე კითხულობდა. შენს checkout-ში არაფერი იწერება, ამიტომ შემდეგი Git pull მას ვერ გადააწერს და შემდეგი push ვერ გამოააშკარავებს.

მეორე გზა .env ფაილია, რომელიც SFTP-ით ატვირთე და არასოდეს დაგიკომიტებია. ორივე ლეგიტიმურია; სხვაობა ისაა, ვის შეუძლია მათი ნახვა და რა ხდება ხელახალი deploy-ისას.

თუ .env-ს იყენებ, .gitignore ჩანაწერი პირველი შედის, სანამ ფაილი არსებობს:

.env.env.*!.env.examplenode_modules/

დააკომიტე .env.example ყველა გასაღებით და მნიშვნელობების გარეშე, რომ შემდეგმა ადამიანმა - შენ რვა თვეში ჩათვლით - იცოდეს, რა სჭირდება აპლიკაციას. Node-ს .env ნატიურად 20.6-დან კითხულობს node --env-file=.env server.js-ით, ამიტომ dotenv პაკეტი მიმდინარე runtime-ზე არჩევითია; Python და Rust პროექტები ჩვეულებრივ python-dotenv-ს და dotenvy-ს იყენებენ.

ორი ფორმატირების წესი, რომელიც რეალურ ბაგებს იწვევს. მნიშვნელობები, რომლებიც შეიცავს ცარიელ ადგილებს, #-ს ან ბრჭყალებს, ციტირებას მოითხოვს, და სხვადასხვა პარსერი escape-ზე არ თანხმდება, ამიტომ, სადაც შეგიძლია, მნიშვნელობები მარტივი გაუშვი. მრავალხაზიანი მნიშვნელობები - private key, service account JSON - environment variable-ში საერთოდ არ ეკუთვნის; დააკოდირე ისინი base64-ით ერთ ხაზად, ან ატვირთე ფაილი და მის ნაცვლად ცვლადში მისი path გადაეცი.

მათი წაკითხვა გამოცნობის გარეშე#

ყოველ ენას ერთი იდიომატური accessor აქვს და ყოველს საკუთარი footgun აქვს გამოტოვებული მნიშვნელობების შესახებ.

const url = process.env.DATABASE_URL;          // undefined when unsetconst port = Number(process.env.PORT ?? 3000); // always parse numbersconst debug = process.env.DEBUG === "true";    // never trust the string

import osurl = os.environ["DATABASE_URL"]       # raises KeyError when unset - goodport = int(os.getenv("PORT", "8000"))  # explicit defaultdebug = os.getenv("DEBUG", "").lower() in {"1", "true", "yes"}

let url = std::env::var("DATABASE_URL").expect("DATABASE_URL is not set");let port: u16 = std::env::var("PORT").unwrap_or_else(|_| "8080".into())    .parse().expect("PORT must be a number");

PHP-ში accessor არის getenv(), და მნიშვნელობები ასევე ჩნდება $_ENV-სა და $_SERVER-ში იმის მიხედვით, როგორ არის runtime მორგებული, რაც web გეგმებზე დაბნეულობის საიმედო წყაროა - მიიჩნიე getenv() და გატესტე.

რა ენაც არ უნდა იყოს, საჭირო ცვლადები გაშვებისას შეამოწმე და გამოდი მკაფიო შეტყობინებით და არ აღმოაჩინო პრობლემა პირველ მოთხოვნაზე დილის ორზე:

const required = ["DATABASE_URL", "SESSION_SECRET", "DISCORD_TOKEN"];const missing = required.filter((name) => !process.env[name]);if (missing.length) {  console.error(`missing environment variables: ${missing.join(", ")}`);  process.exit(1);}

პროცესი, რომელიც გაშვებაზე უარს ამბობს, კარგი შედეგია. პროცესი, რომელიც DATABASE_URL undefined-ით იწყება და სამი დღე ჩუმად ლოკალურ SQLite ფაილში წერს, არა.

რა ეკუთვნის გარემოს#

ყველაფერი, რაც რამეზე წვდომას იძლევა, და ყველაფერი, რაც შენს ლეპტოპსა და სერვერს შორის განსხვავდება.

• ბაზის credential-ები. ამ პანელზე ბაზის სლოტი საკუთარ host-ს, მომხმარებელსა და პაროლს აგენერირებს, ამიტომ სამუშაო ისაა, რომ connection string ცვლადში გადაიტანო და არ გამოიგონო. არასოდეს გამოიყენო ის მეორე აპლიკაციისთვის.
• API გასაღებები და token-ები ყველაფრისთვის, რასაც იძახებ - გადახდის პროვაიდერები, ფოსტის გამგზავნები, ობიექტების საცავი, თამაშის API.
• Webhook URL-ები. Discord-ის ან Slack-ის webhook URL credential-ია: ყველას, ვისაც ის აქვს, შეუძლია შენი სახელით დაწეროს იმ არხზე, სამუდამოდ. მათ საჯარო issue-ებში სხვა ნებისმიერ საიდუმლოზე მეტჯერ ჩასვამენ.
• Bot token-ები. ამ ინდუსტრიაში ყველაზე ხშირად გაჟონილი საიდუმლო. Discord token სრული ანგარიშია; მას scope არ აქვს.
• ხელმოწერისა და სესიის საიდუმლოებები. გასაღები, რომელსაც შენი framework cookie-ების ან JWT-ების ხელმოწერისთვის იყენებს. თუ გაჟონავს, ვინმეს შეუძლია ნებისმიერი მომხმარებლის სახელით ვარგისი სესია გამოუშვას, და მისი შეცვლა ყველას გამოისვამს, ზუსტად ის გაცვლაა, რომელიც ხელმისაწვდომი უნდა გქონდეს.
• RCON და ადმინისტრატორის პაროლები გეიმ სერვერებისთვის. აქ თითო სერვერზე გენერირდება და იმდენივე სერიოზულად უნდა მიიჩნიო, როგორც SSH გასაღები - RCON უსაფრთხოდ განმარტავს, რატომ არის ღია RCON პორტი უფრო ცუდი, ვიდრე ჩანს.
• ყველაფერი, რასაც billboard-ზე არ დაბეჭდავდი, რაც ტესტია, რომელიც იმ შემთხვევებს ფარავს, რომლებიც ზემოთ მოცემულ სიას გამოეპარა.

რა არ ეკუთვნის იქ: დიდი ფაილები, ყველაფერი, რაც გაშვებისას გადატვირთვის გარეშე უნდა შეიცვალოს, და საჯარო კონფიგურაცია, როგორიცაა feature flag, რომელიც რეპოზიტორიაში კარგია. ასევე, საიდუმლოებები არ ჩააგდო შენი გაშვების ბრძანების command line არგუმენტებში - არგუმენტები პროცესების სიებში ისე ჩანს, როგორც გარემო ოდნავ ნაკლებად ჩანს, და ისინი ლოგებში ხვდება.

თუ ის უკვე დაკომიტდა#

შეცვალე. ეს არის მთელი პასუხი და ყველაფერი დანარჩენი სახლის საქმეა.

ხაზის წაშლა და ხელახლა push არ გეხმარება. ძველი commit-ი მნიშვნელობას ჯერ კიდევ შეიცავს და ის ჰეშით მისაწვდომი რჩება force-push-ის შემდეგაც ბევრ ჰოსტინგ კონფიგურაციაში. ყველას, ვინც რეპოზიტორია clone-ა, სრული ისტორია მის დისკზე აქვს. ავტომატური scraper-ები საჯარო რეპოზიტორიებსა და ახალ commit-ებს მუდმივად ადევნებენ თვალს, და ისინი წამებში იზომება და არა საათებში.

თანმიმდევრობა, ბრძანებით:

1. გამოუშვი ახალი credential პროვაიდერთან. გააკეთე ეს ძველის გაუქმებამდე, სადაც პროვაიდერი ორივეს არსებობის საშუალებას იძლევა, რომ არავითარი ხარვეზი არ გქონდეს.
2. ჩააგდე ახალი მნიშვნელობა Startup ჩანართზე და გადატვირთე აპლიკაცია.
3. გააუქმე ძველი credential. ეს ნაბიჯია, რომელსაც ხალხი ტოვებს, რადგან აპი ისევ მუშაობს. ძველი მნიშვნელობა ჯერ კიდევ ვარგისია, სანამ ამას არ გააკეთებ.
4. შეამოწმე, რას შეეხო ძველი. პროვაიდერის dashboard-ები გასაღების მიხედვით ბოლო გამოყენებას აჩვენებს. მოძებნე გამოძახებები, რომლებიც შენ არ გაგიკეთებია, და გამოძახებები მისამართებიდან, რომლებიც შენი არ არის.
5. შემდეგ, სურვილისამებრ, გაასუფთავე ისტორია git filter-repo-თი ან BFG-თი. ეს კოსმეტიკურია. ის არაფერს არ აუღებს გაჟონვას, არღვევს ყოველ არსებულ clone-ს და მე-3 ნაბიჯის შემცვლელი არ არის.

საიდუმლო, რომელიც ხუთი წუთი საჯარო რეპოზიტორიაში იყო, საჯარო საიდუმლოა. Scraper-ები შენზე სწრაფია.

GitHub საჯარო რეპოზიტორიებს კარგად ცნობილ credential ფორმატებზე სკანირებს და პროვაიდერს აცნობებს, სწორედ ამიტომ შეიძლება გაჟონილი cloud გასაღები გამორთული იყოს, სანამ შენ შეამჩნევდე. მას ნუ დაეყრდნობი: ის მონაწილე პროვაიდერების ამოცნობად ნიმუშებს ფარავს, და შენი საკუთარი ხელმოწერის საიდუმლო მათგან არ არის. თუ მტკიცებულება იპოვე, რომ credential გამოიყენეს, რა უნდა გააკეთო, როცა შენი სერვერი გატეხეს უფრო ფართო პროცედურაა.

შეცვლა დაყოვნების გარეშე#

შეცვლა იმდენად მოსაწყენი უნდა იყოს, რომ გრაფიკით აკეთებდე და არა მხოლოდ ინციდენტის შემდეგ. ხერხი დამოკიდებულია იმაზე, შეიძლება თუ არა credential ორჯერ არსებობდეს.

ორი გასაღები ერთდროულად - API პროვაიდერების უმეტესობა და მარტივი შემთხვევა. შექმენი მეორე გასაღები, deploy გააკეთე, დაადასტურე ტრაფიკი ახალ გასაღებზე პროვაიდერის dashboard-ში, წაშალე პირველი. არავითარი შეფერხება, არავითარი კოორდინაცია.

მხოლოდ ერთი მნიშვნელობა - ბაზის პაროლები, სესიის საიდუმლოებები. აქ ცვლილების მომენტია, ამიტომ დაგეგმე: შეცვალე პაროლი ბაზაზე, განაახლე ცვლადი, გადატვირთე. პატარა აპლიკაციაზე ეს კავშირის შეცდომების რამდენიმე წამია, რაც საუკეთესოდ კეთდება, როცა არავინ უყურებს. სესიის საიდუმლოზე მიიღე, რომ ყველა გამოვა, და თუ მნიშვნელოვანია, წინასწარ თქვი.

გაზიარებული სერვისებს შორის - ყველაზე ცუდი შემთხვევა, რადგან ერთის შეცვლა მეორეს არღვევს. გამოსწორება სტრუქტურულია: ერთი credential ყოველი მომხმარებლისთვის, რომ არაფერი იყოს გაზიარებული და შეცვლა ყოველთვის ლოკალური იყოს. ბაზის მომხმარებლები იაფია. შექმენი ერთი თითო აპლიკაციაზე მხოლოდ იმ უფლებებით, რაც სჭირდება, რაც სტანდარტული რჩევაა ბაზის უსაფრთხოების checklist-ში და მიზეზი, რატომ არის connection pool-ები და ლიმიტები ადვილი გასააზრებელი, როცა ყოველ აპს საკუთარი მომხმარებელი აქვს.

ნებისმიერი შეცვლის შემდეგ აიღე ბაზის backup წინაც და შემდეგაც, თუ credential მას შეეხო. ბაზის backup-ები და აღდგენები აღწერს, როგორ გააკეთო ეს მომსახურების ფანჯრის გარეშე.

გზები, რომლებითაც მაინც გაჟონავს#

საიდუმლო გარემოში ჩააგდე და ის მაინც სადღაც საჯაროდ აღმოჩნდა. ხუთი გზა, იმ თანმიმდევრობით, როგორც ისინი რეალურად ხდება:

Build-მა ის ჩაასვა. Front-end ინსტრუმენტები განზრახ აცხობენ ზოგიერთ environment variable-ს JavaScript bundle-ში, რომელსაც ბრაუზერებს აგზავნიან. ყველაფერი, რასაც NEXT_PUBLIC_, VITE_ ან REACT_APP_ ჰქვია, საჯაროა დიზაინით, შიგთავსის მიუხედავად. სერვერული API გასაღები, რომელსაც ერთ-ერთი ეს პრეფიქსი მისცეს, რომ „კომპონენტში იმუშავებოდა“, გასაღებია, რომელიც ყოველი ვიზიტორის ბრაუზერში იბეჭდება. შეამოწმე შენი bundle მნიშვნელობაზე გაგზავნამდე: თუ ბრაუზერის ძებნით პოულობ, ნებისმიერსაც შეუძლია.

რაღაცამ კონფიგურაცია ჩაწერა ლოგში. console.log(process.env) გამართვისას, შეცდომის handler, რომელიც მთელ მოთხოვნის კონტექსტს სერიალიზებს, stack trace framework-ის default შეცდომის გვერდზე production-ში. გამორთე debug გამოტანა production-ისთვის, და თუ შენი ლოგირების ბიბლიოთეკა redaction-ს უჭერს მხარს, ჩამოთვალე მასში შენი საიდუმლო გასაღებები.

ის screenshot-ში ან ticket-ში მოხვდა. მხარდაჭერის საუბრები, bug ანგარიშები, stream-ები. აქ პანელის ticket ყველა თანამშრომელს აღწევს და მასზე დანართები კერძოა, რაც სწორი არხია credential-ისთვის, რომელიც უნდა გაგზავნო - მაგრამ ყველაფერი, რაც ჩატში იყო, ჩათვალე შეცვლილად, მიუხედავად ამისა.

Subprocess-მა ის მემკვიდრეობით მიიღო და ვიღაცას უთხრა. Crash reporter-ები და შეცდომების თვალთვალის SDK-ები ზოგ კონფიგურაციაში ნაგულისხმევად აგროვებენ environment მონაცემებს. წაიკითხე, რას აგზავნის შენი reporter, სანამ ჩართავ.

პანელზე წვდომის მქონემ წაიკითხა. რაც არც ისე გაჟონვაა, როგორც უფლება, რომელიც შენ მიეცი; შემდეგი ნაწილი მის შევიწროებას ეხება.

ვის შეუძლია მათი წაკითხვა პანელზე#

გარემოს ანგარიშის საზღვარი იცავს, ამიტომ სამუშაო ანგარიშშია.

• ორფაქტორიანი ავთენტიფიკაცია მფლობელ ანგარიშზე, აღდგენის კოდებით, რომლებიც სხვაგან ინახება და არა პაროლის მენეჯერში, რომელიც პაროლს ინახავს. ანგარიში, რომელსაც ორივე დაკარგული აქვს, ვერ აღდგება - იხილე ორფაქტორიანი შენს პანელის ანგარიშზე.
• Subuser-ები იმ უფლებით, რაც სჭირდებათ და მეტი არა. როლები აქ საკმარისად დეტალურია, რომ კონსოლი ფაილების გარეშე ან ფაილები ბილინგის გარეშე მისცე, და წვდომა შეიძლება დროით შემოიფარგლოს და გუნდის მეშვეობით შეუერთდეს და არა ინდივიდუალურად დარიგდეს. Subuser-ები და მინიმალური პრივილეგია მოდელს შეიცავს; მოკლე ვერსია ისაა, რომ მოდერატორს, რომელიც სერვერს გადატვირთავს, ჩანართი, რომელიც შენს Stripe გასაღებს აჩვენებს, არ სჭირდება.
• სერვერის activity ლოგი, რომელიც ჩანაწერია, ვინ რა შეცვალა, და პირველი, რასაც უნდა წაიკითხო, როცა მნიშვნელობა ის არ არის, რაც დააყენე.
• მისამართით შეზღუდული API გასაღებები, სესიების სია, საიდანაც შეგიძლია გამოხვიდე, და rate limit-ები login-ზე. გამოიყენე სამივე; ისინი უფასოა.
• ბაზის სლოტის ერთჯერადი შესვლა. phpMyAdmin-ის პანელიდან გახსნა token-ს იყენებს, რომელიც 60 წამში იწურება, ამიტომ credential შენი ბრაუზერის ისტორიაში ან bookmark-ში არ ზის.

როცა ვინმე პროექტს ტოვებს, თანმიმდევრობა ასეთია: ამოიღე subuser, შეცვალე SFTP credential-ები ყველა სერვერისთვის, რომელსაც შეეხო, შეცვალე ყველაფერი, რისი წაკითხვაც შეეძლო. მხოლოდ პირველის გაკეთება ყველაზე გავრცელებული ნახევარზომაა. ანგარიშის გამაგრების სრული სია უსაფრთხოების გვერდზე ცხოვრობს, ხოლო ამავე პრობლემის deploy-მხარის ხედვა Node.js აპის deploy GitHub-იდან-შია.

FAQ#

მართლა უსაფრთხოა environment variable-ები?

ისინი უფრო უსაფრთხოა, ვიდრე ფაილი შენს რეპოზიტორიაში, და დაახლოებით ისეთივე უსაფრთხო, როგორც ფაილი სერვერზე. ისინი არ არის დაშიფრული მოსვენებაში და მათ კითხულობს პროცესი, ყველაფერი, რასაც ის ქმნის, და ყველა, ვისაც Startup ჩანართის ნახვის პანელის უფლება აქვს. ეს საკმარისია თითქმის ყველა პატარა deployment-ისთვის. თუ გჭირდება აუდირებადი, დაშიფრული, თითო მოთხოვნაზე საიდუმლოს მიწოდება, საიდუმლოების მენეჯერი და სხვა არქიტექტურა გჭირდება, და ეს გეცოდინება, რადგან ვიღაც compliance დოკუმენტში დაწერდა.

.env ფაილი უკეთესია თუ უარესი, ვიდრე პანელი?

განსხვავებულია და არა უკეთესი. .env ამუშავებს გრძელ ან უცნაურ მნიშვნელობებს და ყველაფერს ერთ ადგილას ინახავს, რასაც შენი კოდი უკვე კითხულობს. Startup ჩანართი მნიშვნელობას ფაილურ სისტემაში საერთოდ არ ინახავს, ამიტომ ფაილის დონის წვდომა მას არ ავლენს, და ის გადარჩება არასწორ დირექტორიაში შემთხვევით rm-საც. ბევრი ადამიანი პანელს საიდუმლოებისთვის იყენებს და დაკომიტებულ .env.example-ს დოკუმენტაციისთვის, რაც კარგი default-ია.

ჩემი token საჯარო რეპოზიტორიაში დავაპუშე და წავშალე. ყველაფერი რიგზეა?

არა. მნიშვნელობა commit-ის ისტორიაში და ყველა უკვე არსებულ clone-შია, და საჯარო რეპოზიტორიები მუდმივად სკანირდება. გამოუშვი ახალი token, დააყენე, გააუქმე ძველი, შემდეგ შეამოწმე პროვაიდერის გამოყენების ლოგები გამოძახებებზე, რომლებიც შენ არ გაგიკეთებია. ისტორიის შემდეგ გადაწერა სუფთაა, მაგრამ ექსპოზიციას არაფერს ცვლის.

რატომ არის ჩემი ცვლადი undefined მას შემდეგ, რაც დავაყენე?

Environment variable-ები პროცესის დაწყებისას იკითხება, ამიტომ გაშვების შემდეგ დაყენებული მნიშვნელობა არ ჩანს, სანამ არ გადატვირთავ. სხვა კანდიდატები: შეცდომა სახელში, რომელიც რეგისტრის მიმართ მგრძნობიარეა; .env, რომელიც იმ კოდის შემდეგ იტვირთება, რომელიც მას კითხულობს; ან build-time ცვლადი, რომელსაც runtime-ზე ეძებ, რაც სრულიად განსხვავებული მექანიზმია დაბანდულ front-end კოდში.

შემიძლია იგივე ბაზის პაროლი ორი აპლიკაციისთვის გამოვიყენო?

შეგიძლია, და ის ყოველ მომავალ შეცვლას კოორდინირებულ გათიშვად გარდაქმნის. ამის ნაცვლად შექმენი ბაზის მომხმარებელი თითო აპლიკაციაზე მხოლოდ იმ უფლებებით, რაც ამ აპლიკაციას სჭირდება. ის არაფერი ღირს, ზღუდავს, რას შეძლებს ერთი კომპრომეტირებული აპი, და ნიშნავს, რომ credential-ის შეცვლა ერთ პროცესზე მოქმედებს.

სად ჯდება ამაში გეიმ სერვერის პაროლები?

იმავე ადგილას. RCON პაროლები, ადმინისტრატორის პაროლები და გეიმ სერვერის API გასაღებები Startup ჩანართზე დგება და აქ ინსტალაციისას თითო სერვერზე გენერირდება, ამიტომ ნაგულისხმევად უნიკალურია. ერთადერთი სხვაობა ისაა, რომ ზოგი თამაში თავის პაროლს კონფიგურაციის ფაილში წერს, რომელსაც mod-ებს შეუძლიათ წაიკითხონ, ამიტომ ნებისმიერი სერვერი, სადაც მესამე მხარის კოდს აინსტალირებ, ჩათვალე სერვერად, რომლის საიდუმლოებებიც ამ კოდმა იცის - მოდიფიცირებული სერვერის სისუფთავე შესაბამისი ჩვევაა.