ჩვეულებრივი გზა, რომ ვინმეს სერვერის მართვაში დაეხმაროს, არის ანგარიშის პაროლის მიცემა, რომელიც ასევე გადასცემს ბილინგს, შენს ყველა სხვა სერვერს და წაშლის ღილაკს. Subuser-ები იმისთვის არსებობს, რომ კითხვაზე "შეგიძლია გადატვირთო" პასუხი არ იყოს "აი, ყველაფერი". მოდელი საკმარისად მარტივია, რომ ხუთ წუთში დააყენო, მაგრამ ყველა უფლება თანაბრად უსაფრთხო არ არის, და რამდენიმე მათგანი ჩუმად გაცილებით მეტს გადასცემს, ვიდრე მისი სახელი გვაფიქრებინებს. ეს პოსტი გადის თითოეულ ჯგუფს, escalation გზებს, რომლებსაც ხალხი აცდენს, ოთხ როლის განსაზღვრებას, რომლის კოპირებაც შეგიძლია, და იმას, რა უნდა გააკეთო იმ დღეს, როცა ვინმე ჩართული აღარ არის.
რატომ არის ანგარიშის პაროლი ყველაზე ცუდი ვარიანტი#
ღირს იმის ჩამოთვლა, რა მოჰყვება გაზიარებულ პაროლს, რადგან ხალხი ამას ყოველთვის ნაკლებად აფასებს.
- ბილინგი. ინვოისები, გადახდის მეთოდი, საფულის ბალანსი, რამის ყიდვის შესაძლებლობა.
- ანგარიშზე არსებული ყველა სერვერი, და არა მხოლოდ ის, რომელზეც საუბარი იყო.
- წაშლა. სერვერის წაშლა მის backup-ებსაც შლის, დაბლოკილებსაც. უკან დაბრუნება არ არის და ასლი არ რჩება.
- Subuser-ების მართვა, რაც ნიშნავს, რომ მათ შეუძლიათ საკუთარი მეგობრების დამატება შენთვის შეუტყობინებლად.
- შენი მეორე ფაქტორი, ან შენი პაროლის შეცვლა შენ ქვეშ, თუ ისინი იქ პირველები მივიდნენ.
და ორი რამ, რასაც კარგავ და არა გადასცემ. პირველი არის ატრიბუცია: ლოგში ყოველი მოქმედება შენ ხარ, ამიტომ "ვინ გააჩერა" პასუხს არ იღებს. მეორე არის გაუქმება. წვდომის უკან წაღება ნიშნავს პაროლის ყველასთვის ერთდროულად შეცვლას და შენი საკუთარი ავტორიზაციების ხელახლა აღდგენას, სწორედ ამიტომ აგვიანებს ამას ხალხი და ამიტომ გადარჩება გაზიარებული პაროლები მეგობრობებს, რომლებისთვისაც შეიქმნა.
არის ასევე ტრანზიტული პრობლემა. შენი ჰოსტინგი ახლა იმდენად უსაფრთხოა, რამდენადაც მათი პაროლის ჩვევები, მათი ლეპტოპი და ის, იყენებენ თუ არა მეორე ფაქტორს. ორფაქტორიანი ავტორიზაცია შენს პანელის ანგარიშზე მათზეც იმდენადვე ვრცელდება, რამდენადაც შენზე, და შემოწმების საშუალება არ გაქვს.
ამ ყველაფრის წინააღმდეგ "გადატვირთე სერვერი, როცა გაიჭედება" ერთი უფლებაა.
უფლებათა ჯგუფები და რას იძლევა თითოეული რეალურად#
Pterodactyl-ზე აგებული პანელები უფლებებს ერთნაირად აჯგუფებენ, თუმცა ზუსტი სახელები ვერსიებს შორის იცვლება. ქვემოთ არის დაჯგუფება და, რაც უფრო სასარგებლოა, მიზეზი, რატომ არის თითოეული უფრო დიდი, ვიდრე ჩანს.
| ჯგუფი | რას უშვებს | ორჯერ დაფიქრდი, რადგან |
|---|---|---|
| Console | გამოტანის წაკითხვა, ბრძანებების გაგზავნა | კონსოლის ბრძანებებში admin ბრძანებებიც შედის |
| Power | Start, stop, restart, kill | Kill კარგავს ყველაფერს ბოლო შენახვის შემდეგ |
| Files | დათვალიერება, რედაქტირება, ატვირთვა, წაშლა, დაარქივება | ფაილის ჩაწერა არის კოდის გაშვება შემდეგ start-ზე |
| SFTP | იგივე ფაილები ცალკე ავტორიზაციით | მასობრივი გადაცემა, და ლოგში უფრო ადვილად გამოიპარება |
| Backups | შექმნა, აღდგენა, ჩამოტვირთვა, წაშლა | ჩამოტვირთვა ყველა საიდუმლოს ასლია |
| Databases | შექმნა, პაროლის ნახვა, წაშლა | პაროლები ნაჩვენებია და ხშირად სხვაგანაც გამოიყენება |
| Schedules | ამოცანების შექმნა და გაშვება | ამოცანას შეუძლია კონსოლის ბრძანებების გაგზავნა |
| Network | პორტების განაწილების დამატება და მოხსნა | ღია პორტი ახალი წინა კარია |
| Startup | ცვლადების წაკითხვა და შეცვლა | ცვლადები ინახავს token-ებს, გასაღებებს და ავტორიზაციებს |
| Settings | გადარქმევა, reinstall | Reinstall-ს შეუძლია დაყენებული ფაილების წაშლა |
| Users | subuser-ების მოწვევა და მოხსნა | ეს არის მფლობელობა და არა ადმინისტრირება |
| Activity | თითო სერვერის ლოგის წაკითხვა | უვნებელია და ყველასთვის მიცემად ღირს |
ორი ფაქტი ყველა მათგანზე მართებულია. Subuser-ს არასდროს შეიძლება მიენიჭოს მეტი, ვიდრე ანგარიშის მფლობელს აქვს, და ბილინგი საერთოდ არ არის სერვერის უფლება - ის ანგარიშზე ცხოვრობს, ამიტომ არცერთი subuser მას არცერთი კონფიგურაციით ვერ ხედავს. დანარჩენი ყველაფერი შენი გადასაწყვეტია.
Escalation გზები, რომლებსაც ხალხი აცდენს#
მინიმალური პრივილეგია მუშაობს მხოლოდ მაშინ, თუ უფლებები აკეთებენ იმას, რასაც მათი სახელები ამბობენ. რამდენიმე მათგანი არ აკეთებს, და კომბინაციები ის ადგილია, სადაც ხალხი ებმევა.
Schedules კონსოლის აკრძალვას ამარცხებს. დაგეგმილი ამოცანა შეიძლება იყოს კონსოლის ბრძანება. თუ ვინმეს schedule-ების შექმნის უფლებას მისცემ და კონსოლისას არა, მას მაინც შეუძლია ნებისმიერი კონსოლის ბრძანების გაშვება მისი ერთი წუთით მოგვიანებით დაგეგმვით. schedule-ის შექმნა მიიჩნიე კონსოლის წვდომად დაგვიანებით, რადგან ის ასეა.
Files თითქმის ყველაფერს ამარცხებს. ვისაც სერვერის ფაილებში ჩაწერა შეუძლია, შემდეგ start-ზე პროცესს აკონტროლებს. plugin jar-ის ჩანაცვლება, .dll-ის დამატება mod საქაღალდეში, Lua სკრიპტის რედაქტირება ან Python ფაილის ჩაგდება აპლიკაციაში არის კოდის შესრულება შენს კონტეინერში, შენი ქსელის წვდომითა და ფაილურ სისტემით. ფაილებზე წვდომა უფლებაა, რომელიც ყველაზე მეტ დაფიქრებას იმსახურებს, და ის ყველაზე უდარდელად გაიცემა, რადგან "მათ მხოლოდ plugin-ის ატვირთვა სჭირდებათ".
Backup-ის ჩამოტვირთვა არის მონაცემების გატანა. სერვერის არქივი შეიცავს ყველა კონფიგურაციის ფაილს, რომელიც შეიცავს ბაზის პაროლს, RCON პაროლს, ნებისმიერ API token-ს და bot-ზე თავად token-ს. შექმნისა და აღდგენის უფლების მიცემა ჩამოტვირთვის გარეშე თანმიმდევრული პოზიციაა; ჩამოტვირთვის მიცემა შენი საიდუმლოების ასლის მიცემაა.
Startup ცვლადები ნამდვილ ავტორიზაციებს ინახავს. რამდენიმე თამაშს ინსტალაციისთვის შენი ავტორიზაცია სჭირდება: Steam game server token CS2-სა და Unturned-ისთვის, Cfx.re გასაღები FiveM-ისთვის, Klei token Don't Starve Together-ისთვის, BeamMP auth გასაღები. Arma 3-ს, DayZ-ს, Project Zomboid-სა და 7 Days to Die-ს Steam ავტორიზაცია სჭირდება, რომელიც ინახება ისე, როგორც აკრიფეს - სწორედ ამიტომ არის რჩევა, გამოიყენო სათადარიგო Steam ანგარიში და არა მთავარი. ვისაც Startup-ზე წვდომა აქვს, ყველაფრის წაკითხვა შეუძლია.
ბაზის პაროლის ჩვენება. პანელი გენერირებულ პაროლს მოთხოვნით აჩვენებს. თუ ბაზა პანელის გარედან მისაწვდომია, ეს არის პირდაპირი კავშირი ნებისმიერი ადგილიდან, სამუდამოდ, სანამ არ შეცვლი. გარემოს ცვლადები და საიდუმლოებები განიხილავს, როგორ შეინახო ისინი იქ, სადაც ხალხი არ იყურება.
განაწილებები და reinstall. პორტის დამატება ვინმეს საშუალებას აძლევს, გამოაჩინოს სერვისი, რომელიც შენ იქ არ დაგიდია. Reinstall მრავალ თამაშის image-ზე ცვლის დაყენებულ ფაილებს და ძალიან სწრაფი გზაა სამუშაოს დასაკარგად, თუ ადამიანი ღილაკს არასწორად წაიკითხავს.
როლები, გუნდები და grant-ები#
RE:NODE-ის მოდელი სამ რამეს ჰყოფს, რასაც უმეტესი პანელი ერთად ურევს, და როცა გაგიგებ, ბევრ განმეორებით დაკლიკებას გიმარტივებს.
როლი არის უფლებების დასახელებული ნაკრები და არაფერი სხვა: "Moderator" არის console და power, იმის წარმოდგენის გარეშე, ვის აქვს. გუნდი არის ადამიანების ნაკრები და არაფერი სხვა: "Staff" არის ხუთი სახელი, იმის წარმოდგენის გარეშე, რა შეუძლიათ. Grant აერთებს როლს და გუნდს ერთ სერვერთან, სურვილისამებრ დასრულების თარიღით.
სარგებელი მოვლაშია. შეცვალე Moderator როლი ერთხელ და ყველა მოდერატორი ყველა სერვერზე მასთან ერთად იცვლება. მოხსენი ვინმე Staff გუნდიდან და ის ყველგან ერთი და იმავე წამს კარგავს წვდომას, იმ ერთი სერვერის გამოტოვების შანსის გარეშე, რომელიც დაგავიწყდა. ადამიანებს იწვევენ ბმულით, შეერთების კოდით ან ელფოსტით, და ყოველი სერვერი ინახავს საკუთარ activity ლოგს იმისა, რა გაკეთდა და ვინ გააკეთა.
წვდომა თითო სერვერზეა, ამიტომ ვინმეს შეუძლია დაგეხმაროს გადარჩენის სერვერზე და არ იხილოს Discord bot-ი, ბაზა ან მეორე Minecraft სამყარო, რომელზეც ტესტირებ. ეს კარგად ერგება შაბლონს staging და production ერთ ანგარიშზე, სადაც სატესტო სერვერი ის ადგილია, სადაც ადამიანებს დაუდევრობის უფლება აქვთ.
ოთხი როლი, რომლის კოპირებაც ღირს#
Moderator, ანუ ღამის ცვლა. კონსოლის წაკითხვა და გაგზავნა, power start, stop და restart, activity წაკითხვა. სხვა არაფერი. ეს ფარავს "შეგიძლია დაგვეხმარო მართვაში"-ს აბსოლუტურ უმრავლესობას: გადატვირთე, როცა გაიჭედება, წაიკითხე შეცდომა, გააგდე ვინმე, ნახე, რა მოხდა. არც files, არც backups, არც startup.
დაბრკოლება ისაა, რომ კონსოლის ბრძანებები admin ბრძანებებია. Minecraft-ზე op კონსოლის ბრძანებაა, და ასევეა whitelist add. Garry's Mod-ზე lua_run კონსოლის ბრძანებაა და ის თვითნებურ Lua-ს ასრულებს. კონსოლზე წვდომა Source თამაშზე ფაქტობრივად ამ თამაშის სრული კონტროლია. გადაწყვიტე, მისაღებია თუ არა ეს ამ ადამიანისთვის, სანამ მიანიჭებ, და დაუწყვილე თამაშის შიგნით უფლებებს და არ იფიქრო, რომ პანელი ერთადერთი კარიბჭეა.
Plugin-ისა და mod-ის ადმინისტრატორი. Files, SFTP, backup შექმნა, power, console. არა backup წაშლა, არა backup ჩამოტვირთვა, არა ბაზის პაროლი, არა users, არა settings. ეს არის ადამიანი, რომელიც აყენებს და აკონფიგურირებს, და ეს რეალური ნდობაა - იხილე files წვდომის წერტილი ზემოთ. დააწესე წესი, რომ ყოველ ცვლილებამდე backup-ს იღებს, რაც create უფლებას შეუძლია და delete უფლების არქონა ნიშნავს, რომ მას ვერ გააუქმებს.
სანდო თანამფლობელი. ყველაფერი, გარდა users, settings და backup წაშლისა. ეს სამი ის არის, რაც აღწევს დასასრულს: მეტი ადამიანის მოწვევა, გადარქმევა ან reinstall და იმის ჩანაწერის განადგურება, რა იყო სერვერი ადრე. ვინმეს შეუძლია მთელი community-ის ყოველდღიური მართვა მათგან არცერთის გარეშე.
კონტრაქტორი, ანუ ერთჯერადი დახმარება. ზუსტად ის უფლებები, რასაც სამუშაო მოითხოვს, დასრულების თარიღით, რომელიც სამუშაოს ხანგრძლივობას უდრის. გადაიღე backup მათ დაწყებამდე, რომ უარესი შემთხვევა იყოს აღდგენა და არა კამათი, და შეცვალე ავტორიზაციები, რომლებიც მათ შეეძლოთ ენახათ, როცა დაამთავრებენ. Backup-ები, რომლებიც მართლა აღდგება ღირს წასაკითხად, სანამ ამ გეგმას დაეყრდნობი და არა შემდეგ.
| როლი | მიეცი | აუკრძალე |
|---|---|---|
| Moderator | Console, power, activity | Files, SFTP, backups, startup, users |
| Mod admin | Files, SFTP, backup create, console, power | Backup ჩამოტვირთვა და წაშლა, ბაზის პაროლი, users |
| Co-owner | ყველა სერვერის უფლება მარჯვნივ მყოფი სამის გარდა | Users, settings, backup წაშლა |
| Contractor | მხოლოდ ის, რასაც სამუშაო საჭიროებს, დასრულების თარიღით | ყველაფერი დანარჩენი, და მერე შეცვალე ავტორიზაციები |
რასაც ყველა შემთხვევაში იტოვებ: ბილინგი, სერვერის წაშლა, subuser-ების მართვა. ეს სამი მფლობელობაა და არა ადმინისტრირება, და დახმარების არცერთი ფორმა მათ არ საჭიროებს.
Offboarding, რასაც ყველა გამოტოვებს#
ადამიანები community-ს ტოვებენ. წვდომა ჩვეულებრივ რჩება, რადგან მისი მოხსნა არავის საქმეა და დავიწყებისას არაფერი ტყდება. მოკლე სია, რომელიც იმავე დღეს უნდა გაიარო და არა თვის შემდეგ:
- მოხსენი ადამიანი გუნდიდან და არა მხოლოდ ერთი grant-იდან. მოხსნილი grant მათ გუნდში ტოვებს და ერთი კლიკით არიან ხელახლა დამატებადი ნებისმიერისგან, ვისაც users უფლება აქვს.
- შეცვალე RCON პაროლი ყველა სერვერზე, რომელსაც ისინი აღწევდნენ. ეს გაზიარებული საიდუმლოა, ამიტომ მათი ანგარიშის მოხსნა მათ ასლს არ შლის.
- შეცვალე ბაზის პაროლები და ნებისმიერი API token ან bot token, რომელიც იყო კონფიგურაციის ფაილში ან startup ცვლადში, რომლის წაკითხვაც შეეძლოთ.
- თუ Steam ავტორიზაცია ინახებოდა startup ცვლადში, შეცვალე იმ Steam ანგარიშის პაროლი. ის ინახებოდა ისე, როგორც აკრიფეს, და მათ შეეძლოთ წაეკითხათ.
- მოხსენი მათი თამაშის შიგნით admin ცალკე:
ops.jsonMinecraft-ზე,adminlist.txtValheim-ზე,users.iniAMX Mod X-ისთვის,admins.cfgSourceMod-ისთვის, ჯგუფი LuckPerms-ში. პანელმა მათ შესახებ არაფერი იცის. - წაიკითხე activity ლოგი ბოლო რამდენიმე კვირისთვის, სანამ დახურავ, რომ იცოდე, რა მდგომარეობაში ხარ.
- გადაიღე backup და მიანიჭე სახელი, რომ ცვლილების შემდეგ ცნობილი წერტილი გქონდეს.
ნაბიჯები ორიდან ოთხამდე ის არის, რაც მნიშვნელოვანია, რადგან ეს არის წვდომა, რომელიც ანგარიშის წაშლას გადაურჩება.
Activity ლოგი და რას უნდა უყურო#
ყოველი სერვერი ინახავს მასზე ჩადენილი მოქმედებების ლოგს: power მოქმედებები, ფაილების ჩაწერა, backup ოპერაციები, startup ცვლილებები, subuser-ის მოწვევები. უმეტესად ის მოსაწყენია, რაც აზრია - ის იმისთვის არის, რომ ერთი საინტერესო კვირა აღდგეს.
რასაც უნდა მიაქციო ყურადღება, როცა ჩახედავ:
- Power მოქმედებები საათებში, როცა არავინ თამაშობს, განსაკუთრებით stop, რომელსაც start არასდროს მოჰყოლია.
- ფაილების ჩაწერა plugin-ის ან mod-ის დირექტორიაში, რომელიც არ ემთხვევა გამოცხადებულ განახლებას.
- ჩამოტვირთული backup. არსებობს ლეგიტიმური მიზეზები, და არსებობს ასევე მხოლოდ ერთი მიზეზი, რომელიც მნიშვნელოვანია.
- შეცვლილი startup ცვლადები, სადაც ავტორიზაციებია.
- Subuser-ის მოწვევები, რომლებიც შენ არ გაგიგზავნია.
პანელის ლოგი პასუხობს "ვინ", ხოლო კონსოლის ლოგი - "რას ფიქრობდა სერვერი ამაზე". წაიკითხე ერთად - ლოგები, რომლებიც ღირს შენახვად განიხილავს, კონსოლის რომელი გამოტანა ღირს შენახვად, ხოლო კონსოლის კითხვა მის გაგებას.
რასაც subuser-ები ვერ გამოასწორებენ#
უფლებები პანელს წყვეტს. ისინი თამაშს არ წყვეტენ, და ორის აღრევა აქ ყველაზე გავრცელებული შეცდომაა.
გაზიარებული საიდუმლოები გაზიარებულია. RCON პაროლები, ბაზის პაროლები, თამაშის შიგნით admin პაროლები და სერვერის პაროლები ცნობილია ყველასთვის, ვისაც უთხრეს. Subuser-ის მოხსნა მათგან არცერთს არ ცვლის, და სწორედ ამიტომ არსებობს offboarding სია. RCON, უსაფრთხოდ იმ არგუმენტს აჩვენებს, რომ RCON პაროლი საერთოდ არ უნდა ტრიალებდეს.
თამაშის შიგნით უფლებები ცალკე სისტემაა. მოთამაშე, რომელსაც Minecraft-ზე /op მიეცა, ინარჩუნებს მას პანელის წვდომის გაქრობის შემდეგ, რადგან ის სერვერზე ops.json-შია და არა პანელში. იგივე ეხება SourceMod admin ჩანაწერს ან LuckPerms ჯგუფს. LuckPerms ჯგუფები და უფლებები და whitelist-ები და უფლებები ამ პოსტის თამაშის მხარის ნახევარია.
Bot არის აუდიტისთვის მიუწვდომელი subuser. Discord bot admin ბრძანებებით არის ანგარიში, რომლის გამოყენებაც შეუძლია ნებისმიერს, ვისაც Discord-ში სწორი როლი აქვს, და მისი მოქმედებები შენს ლოგებში bot-ად ჩანს. შემოსაზღვრე, რისი გაკეთება შეუძლია, ისე, როგორც ადამიანს შემოსაზღვრავდი.
სუსტი პაროლები სხვაგან. გატეხილი subuser ანგარიში არის შენი გატეხილი სერვერი, შეზღუდული მხოლოდ იმით, რაც მიანიჭე. სწორედ ეს ზღვარია, რასაც მინიმალური პრივილეგია გიძღვნის, და ეს არის არგუმენტი ვიწროდ გაცემისთვის, მათთვისაც კი, ვისაც სრულად ენდობი.
FAQ#
შეუძლია subuser-ს ჩემი სხვა სერვერების ნახვა?
არა. წვდომა თითო სერვერზე გაიცემა, ამიტომ subuser-ს ერთ სერვერზე ანგარიშზე სხვა არაფრის ხილვადობა არ აქვს, არსებობის ჩათვლით. ეს არის მთავარი მიზეზი, რატომ გამოიყენო subuser-ები გაზიარებული პაროლის ნაცვლად, მათთვისაც კი, ვისაც ენდობი.
შეუძლია subuser-ს ბილინგის, ინვოისების ან ჩემი გადახდის მეთოდის ნახვა?
არა. ბილინგი ანგარიშზე ცხოვრობს და არა სერვერზე, ამიტომ სერვერის უფლება მას ვერცერთი კომბინაციით ვერ აღწევს. არ არსებობს subuser-ის კონფიგურაცია, რომელიც მას ხსნის.
შეუძლია subuser-ს სერვერის წაშლა?
მხოლოდ თუ settings-ისა და წაშლის უფლებებს მიანიჭებ, და თითქმის არასდროს არის ამის მიზეზი. წაშლა, subuser-ების მართვა და ბილინგი შენთვის დაიტოვე; დანარჩენი ყველაფერი უსაფრთხოდ შეიძლება გადაეცეს ზემოთ ნახსენები გაფრთხილებებით.
არის პანელის კონსოლზე წვდომა იგივე, რაც თამაშში admin-ობა?
ფაქტობრივად დიახ, უმეტეს თამაშზე, რადგან კონსოლი სერვერის საკუთარ admin ბრძანებებს ასრულებს. ვისაც Minecraft-ზე კონსოლზე წვდომა აქვს, საკუთარ თავს op-ს გაუკეთებს, ხოლო Source თამაშზე თვითნებურ კონფიგურაციას გაუშვებს. კონსოლი მიიჩნიე სანდო როლად და უფრო ვიწრო რამისთვის გამოიყენე თამაშის შიგნით უფლებების სისტემები.
მოქმედებს ჩემი გეგმის შეცვლა subuser წვდომაზე?
არა. გეგმის შეცვლა ცვლის ლიმიტებს სერვერზე, რომელიც უკვე გაქვს და არ აშენებს მას თავიდან, ამიტომ როლები, გუნდები, grant-ები და activity ლოგი უცვლელად გადადის. იგივე ეხება backup-ებსა და ფაილებს.
შემიძლია ვინმეს მივცე წვდომა მხოლოდ შაბათ-კვირისთვის?
დიახ. Grant-ები შეიძლება იყოს დროით შეზღუდული, ამიტომ წვდომა თავისით სრულდება და არ არის დამოკიდებული იმაზე, გახსოვს თუ არა. დაუწყვილე backup-ს, რომელიც შაბათ-კვირამდე გადაიღე, და ავტორიზაციების შეცვლას მის შემდეგ, და ერთჯერადი დახმარება შენთვის არაფერს მუდმივს არ ღირს.




კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.