BURSU PAM

რა არის BURSU PAM

BURSU PAM — BURSUsofts-ის პრივილეგირებული წვდომის კარიბჭე (PAM, Privileged Access Management). ეს არის სერვერი, რომელიც დგას ადმინისტრატორებსა და მათ მიერ სამართავ სერვერებს შორის. ადამიანი სამიზნე სერვერს კი არ უკავშირდება, არამედ კარიბჭეს; კარიბჭე სამიზნე სერვერზე თავად შედის პაროლით ან გასაღებით, რომელსაც ადამიანი ვერ ხედავს და არ იცის, იწერს ყველაფერს, რაც სეანსში ხდება, აუდიტორს საშუალებას აძლევს, სეანსს პირდაპირ ეთერში უყუროს და შეწყვიტოს იგი, ხოლო ყოველ მოქმედებას აუდიტის ჟურნალში იწერს, რომელიც შეუმჩნეველი ცვლილებისგან არის დაცული.

რა შეუძლია კარიბჭეს

ვინ მუშაობს კარიბჭესთან

კონსოლში ოთხი როლია. დეტალურად ისინი განხილულია თავში «როლები»; აქ — იმისთვის, რომ გასაგები იყოს, რომელი თავი ვისთვისაა.

როგორ არის მოწყობილი კარიბჭე

კარიბჭე — ეს არის .NET 10-ის ერთი პროცესი (სერვისი bursu-pam-gateway) თქვენს სერვერზე, PostgreSQL ბაზის გვერდით. ის საკუთარ პორტებზე იღებს ადამიანების კავშირებს, ამოწმებს, დაშვებულია თუ არა კავშირი, თავად ხსნის კავშირს სამიზნე სერვერთან და სეანსს საკუთარ თავში ატარებს, თან იწერს მას.

  მომხმარებელი                                 კარიბჭე BURSU PAM                          სამიზნე სერვერები
 ───────────────                ──────────────────────────────────────────────           ────────────────
  BURSUcm (PAM Gateway) ─HTTPS─►  ვებ-კონსოლი და კლიენტების API (პორტი 443)
                        ─SSH───►  SSH-მსმენელი               (პორტი 2222) ── SSH ──────►  Linux, Unix
  OpenSSH, PuTTY, WinSCP ──────►      │                                   ─── Telnet ───►  ქსელური მოწყობილობები
  mstsc, ფაილი .rdp ───────────►  RDP-მსმენელი               (პორტი 3389) ── RDP ──────►  Windows
  VNC-კლიენტი ─────────────────►  VNC-მსმენელი               (პორტი 5900) ── VNC ──────►  Linux, macOS
  psql / mysql / sqlcmd ───────►  ბაზების მსმენელები   (15432 / 13306 / 11433) ─────────►  ბაზების სერვერები
                                       │
                 წესები · საიდუმლოებები · ჩაწერა · პირდაპირი ყურება · აუდიტი
                                       │
             PostgreSQL (კატალოგი, ჟურნალი)   /var/lib/bursu-pam (გასაღებები, ჩანაწერები)   SIEM (syslog)

ერთი სეანსის გზა

1. შესვლა. მომხმარებელი კარიბჭეს უკავშირდება: BURSUcm-იდან — კონსოლში პაროლითა და TOTP კოდით შესვლის შემდეგ კლიენტი იღებს ერთჯერად ბილეთს (ticket) ერთი კავშირისთვის; ჩვეულებრივი SSH-კლიენტიდან — ლოგინი:სერვერი სახის სახელით, პაროლითა და TOTP კოდით.
2. წესის შემოწმება. კარიბჭე ამოწმებს, არსებობს თუ არა მოქმედი წვდომის წესი (ან დამტკიცებული მოთხოვნა) ამ ადამიანისთვის, სერვერისა და ანგარიშისთვის, და რა არის დაშვებული სეანსში: ტერმინალი, ფაილები, გაცვლის ბუფერი.
3. სამიზნეზე შესვლა. კარიბჭე გაშიფრავს ანგარიშის საიდუმლოს და სამიზნე სერვერზე თავად შედის. SSH-ისთვის ის სამიზნის ჰოსტის გასაღებს ადარებს ადმინისტრატორის მიერ დადასტურებულს, RDP-სა და VNC-სთვის — სერტიფიკატს.
4. ჩაწერა და დაკვირვება. ყველაფერი, რაც სეანსში გადის, ჩაიწერება; აუდიტორი სეანსს პირდაპირ ეთერში ხედავს და შეუძლია მისი შეწყვეტა. ბრძანებებს ბრძანებების კონტროლის პოლიტიკები ამოწმებს.
5. დასრულება. სეანსი მთავრდება, როცა მომხმარებელი გამოდის, უმოქმედობის დრო იწურება, წესს ვადა გასდის ან აუდიტორი მას წყვეტს. ჩანაწერი იხურება და ხელმოიწერება, მოვლენები ხვდება აუდიტის ჟურნალსა და SIEM-ში.

საიდუმლოებები და დაშიფვრის გასაღები

სამიზნე სერვერების პაროლები და გასაღებები ბაზაში დაშიფრული სახით ინახება. მათ შიფრავს კარიბჭის მთავარი გასაღები, რომელიც ინახება გასაღებების კატალოგში /var/lib/bursu-pam/keys და არა ბაზაში. ამიტომ ბაზის ასლი გასაღებების კატალოგის გარეშე უსარგებლოა — მისგან ვერცერთი საიდუმლო და ვერცერთი ჩანაწერი ვერ წაიკითხება. მთავარი გასაღები ორიდან ერთ-ერთი ხერხით არის დაცული, რომელიც პირველადი დაყენების ოსტატში აირჩევა:

• Protected by the operating system (რეკომენდებულია) — გასაღები ინახება ფაილში, რომლის წაკითხვაც მხოლოდ კარიბჭის სერვისს შეუძლია; გადატვირთვის შემდეგ კარიბჭე თავისით ეშვება.
• Sealed with a passphrase — სერვისის ყოველი გადატვირთვის შემდეგ ადმინისტრატორი საიდუმლო ფრაზას შეიყვანს გვერდზე /unseal; სანამ კარიბჭე «დალუქულია», ის არ მუშაობს. იხ. «დალუქული რეჟიმი».

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

აუდიტის ჟურნალი და ჩანაწერები

ყოველი მოვლენა (შესვლა, პარამეტრის შეცვლა, სეანსის დაწყება და დასრულება, ბრძანება, ფაილის გადაცემა…) აუდიტის ჟურნალში იწერება. ჩანაწერები ჰეშების ჯაჭვით არის დაკავშირებული: თითოეული შეიცავს წინას ჰეშს, ხოლო კარიბჭე რეგულარულად სვამს საკონტროლო წერტილებს. თუ ვინმე სტრიქონს პირდაპირ ბაზაში შეცვლის ან წაშლის, ამას მთლიანობის შემოწმება აჩვენებს. სეანსების ჩანაწერები ინახება კატალოგში /var/lib/bursu-pam/recordings ხელმოწერილ აღწერებთან (მანიფესტებთან) და ჰეშებთან ერთად.

გრაფიკული სეანსების იზოლაცია

ყოველი RDP და VNC სეანსი და ჩანაწერის დახატვის ყოველი ამოცანა (პირდაპირი ყურება, დამკვრელი, MP4-ში ექსპორტი) სრულდება ცალკე «მუშა პროცესში» Linux-ის ბირთვის მკაცრი შეზღუდვებით: საკუთარი საკონტროლო ჯგუფი (cgroup v2) მეხსიერების, პროცესებისა და პროცესორის ლიმიტებით, Landlock (ფაილებზე წვდომის აკრძალვა) და seccomp (სისტემური გამოძახებების ფილტრი). ამიტომ კარიბჭეს ბირთვის ეს შესაძლებლობები სჭირდება — იხ. «მოთხოვნები». SSH სეანსები და ვებ-კონსოლი მათზე არ არის დამოკიდებული.

მოთხოვნები

კარიბჭის სერვერი

მონაცემთა ბაზა

საჭიროა PostgreSQL 15 ან უფრო ახალი. ყველაზე მარტივია ლოკალური PostgreSQL 16 Ubuntu-ს არქივიდან: პაკეტი მას თავად ჩამოტვირთავს და შექმნის ბაზას bursu_pam და როლს bursu-pam, რომელიც Unix-სოკეტით შედის პაროლის გარეშე (peer-ავთენტიფიკაცია). შეიძლება გარე PostgreSQL სერვერის გამოყენებაც — მაშინ კარიბჭეზე მხოლოდ PostgreSQL-ის კლიენტია საჭირო და ის პაკეტამდე უნდა დააყენოთ (თორემ apt თავად ჩამოტვირთავს სრულ PostgreSQL სერვერს), ხოლო კავშირის სტრიქონი ცალკე გადაეცემა (იხ. «ბაზა სხვა სერვერზე»).

პორტები

პორტი 22 მანქანის საკუთარ SSH სერვერს რჩება (მისი ადმინისტრირებისთვის), პორტი 5432 — საკუთარ PostgreSQL-ს. ნომრების შეცვლა შეიძლება ბრძანებით bursu-pam-configure. პაკეტი ფაიერვოლს არ ეხება — პორტებს თქვენ ხსნით, იხ. «ქსელი და ფაიერვოლი».

კარიბჭის გამავალი კავშირები: სამიზნე სერვერებთან (მათი SSH, RDP, VNC, Telnet და ბაზების პორტები), დომენის კონტროლერებთან (LDAPS და Kerberos, თუ დირექტორიიდან შესვლა გამოიყენება), SMTP სერვერთან და ვებჰუკების მისამართებთან (შეტყობინებები), SIEM-ის მიმღებთან და — მხოლოდ მაშინ, თუ თავად დააჭერთ ღილაკს ონლაინ-გააქტიურებისთვის ან ჩართავთ ყოველდღიურ შემოწმებას — https://bursucm.com-თან (იხ. «ლიცენზია»). ინტერნეტის გარეშე კარიბჭე სრულად მუშაობს; ლიცენზია მოთხოვნის კოდით აქტიურდება.

სერტიფიკატი

კონფიგურაციის გარეშე კარიბჭე თავად ქმნის თვითხელმოწერილ სერტიფიკატს (ECDSA P-256, ორი წლით), და ბრაუზერი პირველი შესვლისას მასზე გაგაფრთხილებთ — ეს მოსალოდნელია. ორგანიზაციაში სამუშაოდ უმჯობესია სერტიფიკატი გამოუშვათ თქვენი სერტიფიკაციის ცენტრით კარიბჭის სახელზე (მაგალითად pam.example.org) — იხ. «კარიბჭის სერტიფიკატი». თუ VNC ჩართულია, სახელი, რომლითაც კლიენტები კარიბჭეს მიმართავენ, აუცილებლად უნდა იყოს სერტიფიკატში.

მომხმარებლების სამუშაო ადგილები

• ბრაუზერი — ნებისმიერი თანამედროვე, კონსოლისთვის. კონსოლი JavaScript-ის გარეშეც მუშაობს.
• ავთენტიფიკატორის აპი ტელეფონზე TOTP კოდებისთვის (6 ციფრი, 30 წამი, SHA-1): Google Authenticator, Microsoft Authenticator, FreeOTP, Aegis და მსგავსი.
• BURSU Connection Manager (სურვილისამებრ) — Windows ან Linux/macOS, რეჟიმი PAM Gateway. ან ჩვეულებრივი კლიენტები: OpenSSH, PuTTY, WinSCP, FileZilla, mstsc, VNC-კლიენტი, psql, mysql, sqlcmd.

სწრაფი დაწყება: ცარიელი Ubuntu-დან პირველ ჩაწერილ სეანსამდე

ეს გზა დაახლოებით ნახევარ საათში გაივლება. საჭიროა Ubuntu 24.04 (amd64) სერვერი მუდმივი მისამართით, მასზე SSH-წვდომა sudo-ს უფლებებით და ინტერნეტ-წვდომა Ubuntu-ს პაკეტების არქივთან (პაკეტი PostgreSQL-სა და ბიბლიოთეკებს ჩამოტვირთავს). მაგალითებში კარიბჭის მისამართია 192.0.2.10; ჩასვით თქვენი.

1. მოამზადეთ სერვერი. განაახლეთ სისტემა (sudo apt update && sudo apt upgrade), შეამოწმეთ დრო (timedatectl — სტრიქონი System clock synchronized: yes) და, თუ Kerberos-ით შესვლა იქნება, მიუთითეთ ჰოსტის სრული სახელი (sudo hostnamectl set-hostname pam.example.org).
2. დააკოპირეთ პაკეტი და შეამოწმეთ მისი ნამდვილობა. დააკოპირეთ სერვერზე გამოშვების მთელი საქაღალდე, რომელიც BURSUsofts-ისგან მიიღეთ (მასშია .deb, SHA256SUMS, SHA256SUMS.asc და გასაღები bursu-pam-release.gpg), და ამ საქაღალდეში შეასრულეთ შემოწმება განყოფილებიდან «პაკეტის შემოწმება».
3. დააყენეთ პაკეტი ერთი ბრძანებით.

   sudo apt install ./bursu-pam_1.0.0_amd64.deb

   პაკეტი შექმნის ანგარიშს bursu-pam, კატალოგებს, ბაზას bursu_pam და ფაილს /etc/bursu-pam/gateway.json, შემდეგ კი თავად დაგისვამთ რამდენიმე კითხვას მისამართისა და პორტების შესახებ. დააჭირეთ Enter-ს ყოველ კითხვაზე — ნაგულისხმევი მნიშვნელობები ერთ სერვერზე მომუშავე კარიბჭეს იძლევა, — და ბოლოს უპასუხეთ y კითხვას Apply?. დეტალურად — «პორტები და პროტოკოლები».
4. ჩაიწერეთ მისამართი და დაყენების კოდი. ინსტალაციის ბოლო სტრიქონები ასე გამოიყურება:

     Open in a browser:  https://192.0.2.10/setup
     Setup code:         XXXX-XXXX-XXXX

   კოდი ერთჯერადია; თუ დაკარგეთ — sudo cat /var/lib/bursu-pam/setup-code.
5. გახსენით პორტები. თუ სერვერზე ufw ჩართულია, ინსტალერმა მზა ბრძანებები sudo ufw allow …/tcp დაბეჭდა — შეასრულეთ ისინი. თუ მომხმარებლებსა და კარიბჭეს შორის სხვა ფაიერვოლია — იგივე პორტები იქაც გახსენით. იხ. «ქსელი და ფაიერვოლი».
6. გაიარეთ პირველადი დაყენების ოსტატი. გახსენით https://192.0.2.10/setup ბრაუზერში, თვითხელმოწერილი სერტიფიკატის შესახებ გაფრთხილების მიუხედავად დაეთანხმეთ გაგრძელებას და გაიარეთ 7 ნაბიჯი: დაყენების კოდი → ენა → გასაღების რეჟიმი → აღდგენის გასაღები (ამობეჭდეთ) → პირველი ადმინისტრატორი → TOTP და აღდგენის კოდები → მზადაა. დეტალურად — «პირველადი დაყენება».
7. შედით და ჩართეთ ლიცენზია. დააჭირეთ Go to sign-in, შედით პაროლითა და აპის კოდით, გახსენით Settings → Licence. თუ ინტერნეტი გაქვთ — Start the 7-day trial online → Send this one call. თუ არა — Start the 7-day trial ბლოკში Request codes (offline), შემდეგ კოდი bursucm.com-ზე შეიყვანება ნებისმიერი კომპიუტერიდან. სანამ ლიცენზია არ არის, კარიბჭე არცერთ სეანსს არ უშვებს და არაფრის შეცვლის საშუალებას არ იძლევა. დეტალურად — «ლიცენზია».
8. დაამატეთ სერვერი. Servers → Create server: სახელი, პროტოკოლი SSH, მისამართი და პორტი. სერვერის ბარათზე დაადასტურეთ ჰოსტის გასაღები. დეტალურად — «სერვერები».
9. დაამატეთ სერვერის ანგარიში. სერვერის ბარათზე, ანგარიშების ჩანართზე (ან Accounts → Add account): ლოგინი სამიზნე სერვერზე და მისი პაროლი ან SSH-გასაღები. კარიბჭე საიდუმლოს დაშიფრულს შეინახავს; მისი ჩვენება შემდეგ შეუძლებელია. იხ. «ანგარიშები და საიდუმლოებები».
10. შექმენით მომხმარებელი. Users → Create user: ლოგინი, სახელი, როლი User, დროებითი პაროლი. პირველი შესვლისას ის პაროლს შეცვლის და TOTP-ს მიაბამს. იხ. «მომხმარებლები».
11. შექმენით წვდომის წესი. Access rules → Create rule: ვინ (მომხმარებელი ან ჯგუფი), რასთან (სერვერი და ანგარიში), რა არის დაშვებული (ტერმინალი, ფაილები). იხ. «წვდომის წესები».
12. დაუკავშირდით. BURSUcm-იდან: შენახვის რეჟიმი PAM Gateway, კარიბჭის მისამართი, მომხმარებლის შესვლა — სერვერი კატალოგში გამოჩნდება, ორმაგი დაწკაპუნება სეანსს ხსნის (დეტალურად). ან ნებისმიერი ტერმინალიდან:

    ssh -p 2222 ivanov:web01@192.0.2.10

    სადაც ivanov — კარიბჭის მომხმარებლის ლოგინია, web01 — სერვერის სახელი კონსოლში; კარიბჭე მომხმარებლის პაროლსა და TOTP კოდს მოითხოვს (დეტალურად).
13. ნახეთ ჩანაწერი. შედით კონსოლში ადმინისტრატორად: Sessions აჩვენებს მიმდინარე სეანსს (მისი პირდაპირ ეთერში ყურება და შეწყვეტა შეიძლება), გამოსვლის შემდეგ კი — ჩანაწერს აკრეფილი ტექსტით ძებნის შესაძლებლობით. იხ. «სეანსები და ჩანაწერები».

პაკეტის ინსტალაცია

პაკეტის შემოწმება

გამოშვება მიეწოდება საქაღალდის სახით და არა ერთი ფაილით. მასშია: პაკეტი bursu-pam_1.0.0_amd64.deb, inputs.manifest (საიდან არის აწყობილი პაკეტი), lintian.txt (პაკეტის შემოწმების ანგარიში), ტესტების ანგარიში suite-report.<კომიტი>.txt, საკონტროლო ჯამების სია SHA256SUMS, მისი ხელმოწერა SHA256SUMS.asc და BURSUsofts-ის ღია გასაღები bursu-pam-release.gpg. დააკოპირეთ სერვერზე მთელი საქაღალდე და მასში შეასრულეთ:

gpg --show-keys --with-colons bursu-pam-release.gpg | grep '^fpr'
gpgv --keyring ./bursu-pam-release.gpg SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS

• პირველი ბრძანება გასაღების ანაბეჭდს ბეჭდავს. შეადარეთ ის ანაბეჭდს, რომელიც BURSUsofts-მა სხვა არხით შეგატყობინათ (წერილით, ტელეფონით), — და არა იმას, რაც პაკეტის გვერდით დევს: gpgv ენდობა ნებისმიერ გასაღებს მისთვის გადაცემული ფაილიდან.
• მეორე ბრძანება შეცდომების გარეშე უნდა დასრულდეს: gpgv წერს Good signature, ხოლო sha256sum -c — OK-ს ოთხივე ფაილისთვის. BAD signature ნიშნავს, რომ ჯამების სია შეცვლილია; FAILED ფაილთან — რომ თავად ფაილია შეცვლილი ან დაზიანებული. ორივე შემთხვევაში პაკეტი არ დააყენოთ და დაუკავშირდით მომწოდებელს.
• თუ მხოლოდ .deb დააკოპირეთ, sha256sum -c სამი ფაილის არარსებობას შეგატყობინებთ — ეს დაზიანება კი არა, არასრული საქაღალდეა.

ინსტალაცია

sudo apt install ./bursu-pam_1.0.0_amd64.deb

ფაილის სახელის წინ ./ აუცილებელია — თორემ apt პაკეტს რეპოზიტორიებში მოძებნის. apt დამოკიდებულებებს Ubuntu-ს არქივიდან თავად ჩამოტვირთავს: PostgreSQL 16, Kerberos-ის ბიბლიოთეკები (libgssapi-krb5-2), ICU, OpenSSL, jq და სხვა.

რას აკეთებს პაკეტი

ფაილების გაშლის შემდეგ პაკეტი უშვებს პროგრამას bursu-pam-setup (მისი ხელახლა გაშვებაც შეიძლება — მეორე გაშვება არაფერს ცვლის). თანმიმდევრობით:

1. ანგარიში. ქმნის ლოკალურ სისტემურ ანგარიშს bursu-pam: პაროლის გარეშე, შესვლის გარსის გარეშე, საკუთარი ჯგუფით, რომელშიც სხვა არავინ არის, და დამატებითი ჯგუფების გარეშე. თუ ასეთი სახელის ანგარიში უკვე არსებობს, მაგრამ ამ მოთხოვნებს არ შეესაბამება (მაგალითად, ჯგუფ docker-ის წევრია ან გარსი აქვს), ინსტალაცია ჩერდება და ასახელებს ბრძანებას, რომლითაც ეს გასწორდება.
2. კატალოგები. /etc/bursu-pam (root:bursu-pam, 0750), /var/lib/bursu-pam (bursu-pam, 0700), /var/backups/bursu-pam (root, 0700). არსებული კატალოგების შიგთავსს არასოდეს ეხება.
3. მონაცემთა ბაზა. PostgreSQL 15+ ვერსიის პირველ მომუშავე ლოკალურ კლასტერზე ქმნის როლს bursu-pam (მხოლოდ LOGIN, პაროლისა და განსაკუთრებული უფლებების გარეშე) და ბაზას bursu_pam, რომლის მფლობელიც ეს როლია და რომელზეც სხვა არავის აქვს წვდომა. ფაილებს pg_hba.conf და postgresql.conf არ ცვლის.
4. შესვლის შემოწმება. რწმუნდება, რომ როლი თავის ბაზაში Unix-სოკეტით შედის peer-ავთენტიფიკაციით — პაროლის გარეშე.
5. კონფიგურაცია. წერს /etc/bursu-pam/gateway.json-ს (root:bursu-pam, 0640) — მხოლოდ თუ ის ჯერ არ არსებობს. არსებული ფაილი არასოდეს გადაიწერება; თუ პაკეტი სხვა შიგთავსს შემოგთავაზებდათ, ის გვერდით ინახება gateway.json.proposed-ის სახით.

შემდეგ პაკეტი უშვებს შემოწმებას bursu-pam-check --quiet (ბეჭდავს მხოლოდ გაფრთხილებებსა და შეცდომებს, ინსტალაციას არ წყვეტს), რთავს სერვისს bursu-pam-gateway და — ახალი ინსტალაციისას ტერმინალში — სვამს კითხვებს პორტების შესახებ (შემდეგი თავი), რის შემდეგაც კარიბჭეს უშვებს.

პირველი გაშვებისას კარიბჭე თავად ქმნის ბაზაში თავის ცხრილებს, მონაცემთა კატალოგში კი — თვითხელმოწერილ სერტიფიკატს და ფაილს დაყენების ერთჯერადი კოდით /var/lib/bursu-pam/setup-code.

რა სად არის

პაკეტი არ შეიცავს არც პაროლებს, არც გასაღებებს, არც სერტიფიკატებს და არც ლიცენზიას.

როგორ გამოიყურება ინსტალაცია ტერმინალში

ახალი ინსტალაციის გამონატანის მაგალითი სერვერზე მისამართით 192.0.2.10 (შედგენილია ინსტალაციის სკრიპტების ტექსტების მიხედვით; თავად apt-ის სტრიქონები შემოკლებულია). თქვენი სტრიქონები შეიძლება ოდნავ განსხვავდებოდეს — მაგალითად, შემოწმების გაფრთხილებების შემადგენლობით.

$ sudo apt install ./bursu-pam_1.0.0_amd64.deb
…
Setting up bursu-pam (1.0.0) ...
bursu-pam-setup: account bursu-pam: created (system account, no login shell, no password)
bursu-pam-setup: /etc/bursu-pam: created root:bursu-pam 0750
bursu-pam-setup: /var/lib/bursu-pam: created bursu-pam:bursu-pam 0700
bursu-pam-setup: /var/backups/bursu-pam: created root:root 0700
bursu-pam-setup: PostgreSQL 16/main: role bursu-pam created (LOGIN only, no password)
bursu-pam-setup: PostgreSQL 16/main: database bursu_pam created, owned by bursu-pam, closed to PUBLIC
bursu-pam-setup: peer authentication of bursu-pam over /var/run/postgresql: ok
bursu-pam-setup: /etc/bursu-pam/gateway.json: written (root:bursu-pam 0640)
WARN hostname: the host name pam is not fully qualified; Kerberos needs the FQDN (…)
bursu-pam postinst: a few questions follow (Enter takes the default; Ctrl+C keeps the defaults; later: sudo bursu-pam-configure)
BURSU PAM gateway - listeners and ports
Press Enter to take the value in [brackets]. Nothing changes until you confirm at the end.
…  (კითხვები — იხ. შემდეგი თავი)
  Open in a browser:  https://192.0.2.10/setup
  Setup code:         XXXX-XXXX-XXXX
  (lost it? sudo cat /var/lib/bursu-pam/setup-code)
  (the browser will warn about the self-signed certificate - expected; continue)

ინსტალაცია კითხვების გარეშე

კითხვები ისმება მხოლოდ მაშინ, თუ ეს ახალი ინსტალაციაა, გამონატანი ტერმინალში გადის, systemd მუშაობს და არ არის მითითებული არც DEBIAN_FRONTEND=noninteractive, არც BPAM_NO_WIZARD=1. სხვა შემთხვევებში (ავტომატიზებული ინსტალაცია, განახლება) კარიბჭე ნაგულისხმევი პორტებით ეშვება (კონსოლი 443, SSH 2222; RDP, VNC და ბაზების მსმენელები გამორთულია), კოდის ნაცვლად კი იბეჭდება მხოლოდ ბრძანება, რომელიც მას აჩვენებს:

sudo DEBIAN_FRONTEND=noninteractive apt install -y ./bursu-pam_1.0.0_amd64.deb
sudo bursu-pam-configure --next-steps        # მისამართი ბრაუზერისთვის და დაყენების კოდი

პორტების მითითება მოგვიანებით შეიძლება იმავე ბრძანებით sudo bursu-pam-configure.

ბაზა სხვა სერვერზე

თუ ბაზა ცალკე PostgreSQL სერვერზე იქნება (ვერსია 15+), იქ როლი და ბაზა თავად შექმენით (ბაზის მფლობელი — ეს როლია; როლს ზედმეტი უფლებები არ მისცეთ) და კარიბჭეს Npgsql-ის კავშირის სტრიქონი გადაეცით.

პაროლიანი სტრიქონი გადაეცით მხოლოდ სტანდარტული შეყვანით, რომ პროცესების სიაში არ მოხვდეს. გადამისამართებას < თქვენი გარსი ასრულებს და არა sudo, ამიტომ სტრიქონიანი ფაილი თქვენთვის უნდა იყოს ხელმისაწვდომი: ჩადეთ ის თქვენს საშინაო კატალოგში უფლებებით მხოლოდ თქვენთვის.

(umask 077; nano ~/pam-connstring.txt)        # ერთი სტრიქონი, იხ. ქვემოთ
sudo bursu-pam-setup --connection-string - < ~/pam-connstring.txt
rm ~/pam-connstring.txt
sudo systemctl enable --now bursu-pam-gateway
sudo bursu-pam-configure

ფაილში — ერთი სტრიქონი, მაგალითად:

Host=db.example.org;Port=5432;Database=bursu_pam;Username=bursu_pam;Password=…;SSL Mode=VerifyFull

ფაილი წაშალეთ კონფიგურაციის ჩაწერისთანავე (მეორე ბრძანება). გახსოვდეთ: ამ შემთხვევაში ბაზის პაროლი ინახება gateway.json-ში (ფაილს მხოლოდ root და სერვისი კითხულობენ), პაკეტი კი განახლების წინ ბაზის ავტომატურ ასლს არ ქმნის — ასლს ბაზის სერვერზე თქვენ აკეთებთ.

თუ ინსტალაციისას ჰოსტზე მომუშავე PostgreSQL არ აღმოჩნდა (ან კლიენტი ვერ მოიძებნა), პაკეტი შეგატყობინებთ provisioned except the database და კარიბჭეს არ გაუშვებს — გასწორების შემდეგ კიდევ ერთხელ შეასრულეთ sudo bursu-pam-setup და sudo systemctl enable --now bursu-pam-gateway.

პორტები და პროტოკოლები: bursu-pam-configure

bursu-pam-configure — მოკლე ოსტატი ტერმინალში, რომელიც კარიბჭის მისამართსა და პორტებს ადგენს. ახალი ინსტალაციისას მას თავად პაკეტი იძახებს; მოგვიანებით მისი გაშვება რამდენჯერაც გინდათ, შეიძლება:

sudo bursu-pam-configure                 # კითხვები; Enter — მნიშვნელობა [ფრჩხილებში]
sudo bursu-pam-configure --next-steps    # მხოლოდ: სად გადავიდეთ ბრაუზერში და დაყენების კოდი

ბოლო კითხვაზე y-ით პასუხამდე არაფერი იცვლება. ხელახლა გაშვებისას ნაგულისხმევ მნიშვნელობებად მიმდინარე პარამეტრები იქცევა.

კითხვები

ოსტატი არ მოგცემთ საშუალებას აირჩიოთ პორტი, რომელიც უკვე სხვა პროგრამას უკავია (დაასახელებს მას და პროცესის ნომერს), ორჯერ არჩეული პორტი და პორტი 5432. ხელახლა გაშვებისას ადრე გამორთული პროტოკოლი ნაგულისხმევად გამორთულად არის შემოთავაზებული.

თუ VNC ჩართულია, კარიბჭის მიერ შექმნილი სერტიფიკატი კი არჩეულ მისამართს არ შეიცავს, ოსტატი იკითხავს Let the gateway make a new certificate? (the old one is kept as a .bak file). პასუხი y ძველ სერტიფიკატს განზე გადადებს (ასლი gateway.pfx.bak-…), და კარიბჭე ამ მისამართით ახალს ქმნის. ბრაუზერები და BURSUcm-ის კლიენტები, რომლებიც უკვე ენდობოდნენ ძველ სერტიფიკატს, ერთხელ კვლავ მოითხოვენ დადასტურებას. პასუხით n VNC პარამეტრებში ჩაწერილი რჩება, მაგრამ კარიბჭე მას არ გახსნის (Settings → VNC-ზე ეწერება Address not in the certificate), სანამ სერტიფიკატში ეს სახელი არ იქნება; ბოლოს ოსტატი დაწერს, რომ VNC ჯერ არ უსმენს. თუ საკუთარი სერტიფიკატი დააყენეთ (certificatePath), ეს კითხვა არ ისმება — სახელი თქვენს სერტიფიკატში წინასწარ უნდა იყოს.

რა ხდება «y»-ის შემდეგ

1. მიმდინარე gateway.json კოპირდება /etc/bursu-pam/gateway.json.bak-<UTC დრო>-ში.
2. gateway.json-ში იწერება მხოლოდ პასუხები; ყველა სხვა პარამეტრი უცვლელი რჩება.
3. კარიბჭე გადაიტვირთება; ოსტატი 20 წამამდე ელოდება, სანამ კონსოლის პორტი უპასუხებს (პირველი გაშვებისას, სანამ კარიბჭე ბაზას ამზადებს, — 60 წამამდე, და ამის შესახებ წერს).
4. თუ კარიბჭე არ ამუშავდა, წინა ფაილი (და წინა სერტიფიკატი) თავის ადგილს უბრუნდება, კარიბჭე მასთან ერთად გადაიტვირთება, და ოსტატი სერვისის ჟურნალის ბოლო 30 სტრიქონს აჩვენებს — მათგან ჩანს, რა არის არასწორად. დასრულების კოდი 1.
5. თუ ამუშავდა — ოსტატი გატყობინებთ, რომელი პორტები უსმენენ უკვე. SSH, RDP, VNC და ბაზების მსმენელები იხსნება მხოლოდ ოსტატის /setup დასრულების შემდეგ (დალუქულ რეჟიმში კი — ლუქის მოხსნის შემდეგ), ამიტომ მანამდე ის წერს opens once the first-run setup in the console is finished.
6. ბოლოს — ჰოსტის შემოწმების სტრიქონები, დანომრილი შემდეგი ნაბიჯები (მზა ბრძანებებით sudo ufw allow …/tcp, თუ ufw ჩართულია; თავად ოსტატი ფაიერვოლს არ ცვლის) და კონსოლის მისამართი დაყენების კოდთან ერთად.

დიალოგის მაგალითი (Enter ყველგან, ბოლო კითხვის გარდა):

1. The address people and their programs use to reach this gateway: a DNS name (pam.example.org) or an IP address.
   The console link and VNC sessions use it.
   Address [192.0.2.10]:

2. The web console (administration, and where users sign in) is served over HTTPS.
   Console HTTPS port [443]:

3. SSH: people connect their SSH client (ssh, PuTTY) to the gateway, which signs in to the target server for them.
   SSH port (not 22: the server's own SSH keeps it) [2222]:

4. Let people open RDP (Windows remote desktop) sessions through the gateway? [Y/n]:
   RDP port [3389]:

5. Let people open VNC (remote screen of Linux and macOS desktops) sessions through the gateway? [Y/n]:
   VNC port [5900]:

6. Database fronts: people connect their usual database tool to the gateway, which signs in to the database server for them.
   Port 5432 is not offered: this server's own PostgreSQL, which holds the gateway's data, uses it.
   Offer PostgreSQL through the gateway? [Y/n]:
   PostgreSQL front port [15432]:
   Offer MySQL / MariaDB through the gateway? [y/N]:
   Offer Microsoft SQL Server through the gateway? [y/N]:

Summary:
  Address                192.0.2.10
  Console (HTTPS)        https://0.0.0.0:443
  SSH                    0.0.0.0:2222
  RDP                    0.0.0.0:3389
  VNC                    192.0.2.10:5900
  PostgreSQL front       192.0.2.10:15432
  MySQL front            off
  SQL Server front       off

Apply? This restarts the gateway; open sessions are closed. [y/N]: y

Saved. The previous file is /etc/bursu-pam/gateway.json.bak-20261102T101500Z. Restarting the gateway...
The gateway runs with the new settings.
  SSH (port 2222) opens once the first-run setup in the console is finished.
  RDP (port 3389) opens once the first-run setup in the console is finished.
  VNC (port 5900) opens once the first-run setup in the console is finished.
  PostgreSQL front (port 15432) opens once the first-run setup in the console is finished.

Checking this server (bursu-pam-check --quiet):

Next steps:
  1. Open https://192.0.2.10/setup in a browser.
  2. Enter the one-time setup code (below).
  3. In the console: create the administrator, then install the licence.
  4. The firewall (ufw) is on. Let the gateway's ports in:
       sudo ufw allow 443/tcp
       sudo ufw allow 2222/tcp
       sudo ufw allow 3389/tcp
       sudo ufw allow 5900/tcp
       sudo ufw allow 15432/tcp

----------------------------------------------------------------------------------------------
  Open in a browser:  https://192.0.2.10/setup
  Setup code:         XXXX-XXXX-XXXX
  (lost it? sudo cat /var/lib/bursu-pam/setup-code)
  (the browser will warn about the self-signed certificate - expected; continue)

როცა ოსტატი /setup უკვე გავლილია, /setup-ის მისამართისა და კოდის ნაცვლად იბეჭდება Console: https://…/.

დასრულების კოდები

პირველადი დაყენება (ოსტატი /setup)

სანამ კარიბჭე არ არის დაყენებული, მასში მხოლოდ ერთი გვერდია — https://<მისამართი>/setup; ნებისმიერი სხვა მისამართი მასზე გადაგიყვანთ. შვიდნაბიჯიანი ოსტატი ქმნის დაშიფვრის გასაღებს, პირველ ადმინისტრატორს და ძირითად პარამეტრებს. პირველ რიგში ის ერთჯერად კოდს ითხოვს — რომ კარიბჭე არ «დაიკავოს» იმან, ვინც გვერდს პირველი გახსნის.

ნაბიჯი 1 · Setup code

შეიყვანეთ კოდი ინსტალაციის გამონატანიდან (ფორმატი XXXX-XXXX-XXXX, 12 სიმბოლო; დეფისებსა და რეგისტრს მნიშვნელობა არ აქვს). თუ გამონატანი დაიკარგა: sudo cat /var/lib/bursu-pam/setup-code ან sudo bursu-pam-configure --next-steps. ფაილს მხოლოდ სერვისი და root კითხულობენ; მისი გზა სერვისის ჟურნალშიც იწერება (თავად კოდი — არასოდეს). არასწორი კოდი: The setup code did not match. ერთი მისამართიდან — წუთში არაუმეტეს 10 მცდელობისა.

ნაბიჯი 2 · Language

Default console language — კონსოლის ნაგულისხმევი ენა: English, Русский, Українська, ქართული, Deutsch, Español, Português, Português (Brasil). თითოეული მომხმარებელი შემდეგ საკუთარ ენას პროფილში და შესვლის გვერდზე ირჩევს.

ნაბიჯი 3 · Key mode

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

• Protected by the operating system (recommended) — გასაღები ინახება გასაღებების კატალოგში, მისი წაკითხვა მხოლოდ სერვისს შეუძლია. გადატვირთვის შემდეგ კარიბჭე თავისით ეშვება. აირჩიეთ ეს ვარიანტი, თუ დარწმუნებული არ ხართ.
• Sealed with a passphrase — სერვისის ყოველი გადატვირთვის შემდეგ ადმინისტრატორი საიდუმლო ფრაზას შეიყვანს გვერდზე /unseal. დისკის მოპარვისას უფრო საიმედოა, მაგრამ სანამ კარიბჭე დალუქულია, ის არ მუშაობს (ვერავინ დაუკავშირდება). მიუთითეთ Passphrase და Repeat the passphrase — არანაკლებ 12 სიმბოლოსი.

რეჟიმის შეცვლა მოგვიანებით შეიძლება Settings → Encryption key-ში (დეტალურად).

ნაბიჯი 4 · Recovery key

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

1. დააჭირეთ Download .txt ან Print და გასაღები ქსელის გარეშე შეინახეთ: ამონაბეჭდი — სეიფში, ფაილი — მატარებელზე, რომელიც სერვერისგან ცალკე ინახება. გასაღები თავად კარიბჭეზე არ შეინახოთ.
2. მონიშნეთ I have saved the key in a safe place.
3. ველში Last 4 characters of the key შეიყვანეთ გასაღების ბოლო 4 სიმბოლო — ეს შემოწმებაა, რომ გასაღები მართლაც ჩაწერილია.

ნაბიჯი 5 · Administrator

პირველი ადმინისტრატორი; დანარჩენ მომხმარებლებს ის კონსოლში შექმნის.

ნაბიჯი 6 · Two-factor sign-in

1. დაასკანერეთ QR-კოდი ავთენტიფიკატორის აპით ან შეიყვანეთ გასაღები ხელით (პარამეტრები: SHA-1, 6 ციფრი, 30 წამი).
2. შეიყვანეთ Code from the app-ში მიმდინარე ექვსნიშნა კოდი და დააჭირეთ Next. The code did not match. Check the time on the phone. — შეამოწმეთ დრო ტელეფონზე.
3. ოსტატი ათ აღდგენის კოდს აჩვენებს — თითოეული ერთხელ მუშაობს, ტელეფონის დაკარგვის შემთხვევისთვის. შეინახეთ ისინი ტელეფონისგან ცალკე, მონიშნეთ I have saved the recovery codes და დააჭირეთ Next.

ნაბიჯი 7 · Done

შედეგი: გასაღების რეჟიმი, ადმინისტრატორი დაყენებული მეორე ფაქტორით, და Setup code — no longer valid, the file is deleted. ორი ღილაკი: Go to sign-in — შესვლის ჩვეულებრივი გვერდი, და Next: start the 7-day trial or install a licence — Settings → Licence. კარიბჭე არცერთ სეანსს არ უშვებს, სანამ ლიცენზია არ აქვს — დაუყოვნებლივ გადადით თავზე «ლიცენზია».

თუ ოსტატი შეწყდა

ოსტატის მსვლელობა ინახება მხოლოდ კარიბჭის მეხსიერებაში და ბრაუზერზეა მიბმული; 30 წუთის უმოქმედობის შემდეგ, სერვისის გადატვირთვისას ან დაყენების კოდის ხელახლა შეყვანისას ის იშლება. თუ ფანჯარა დახურეთ, გახსენით /setup, ხელახლა შეიყვანეთ დაყენების კოდი (ის ოსტატის დასრულებამდე მოქმედებს) და ხელახლა აირჩიეთ ენა. შემდეგ ოსტატი იმ ადგილიდან გააგრძელებს, რომელიც უკვე შესრულებულით განისაზღვრება: თუ გასაღები შექმნილია, ნაბიჯ 3-ზე არჩევანი გამოჩნდება; თუ ადმინისტრატორი შექმნილია — ოსტატი პირდაპირ ნაბიჯ 6-ზე გადავა. არ დახუროთ გვერდი, სანამ აღდგენის გასაღებს არ შეინახავთ: ის ერთხელ ჩანს და ნაბიჯ 4-ზე ჩანართის დახურვის შემდეგ ხელახლა აღარ გამოჩნდება. თუ გასაღები წინა ჯერზე უკვე შეიქმნა, ნაბიჯ 3-ზე გამოჩნდება არჩევანი: Continue with this key (თუ მისი აღდგენის გასაღები შეინახეთ) ან Create the key again — ძველი გასაღები და მისი აღდგენის გასაღები იშლება; ეს შესაძლებელია მხოლოდ მანამ, სანამ არც ადმინისტრატორი არსებობს და არც არცერთი საიდუმლო. თუ გასაღებების კატალოგში წაშლილი გასაღების ფაილები დარჩა, ოსტატი მათ დაასახელებს — გადაიტანეთ ისინი სხვა ადგილას და გაიმეორეთ.

დალუქული რეჟიმი და /unseal

გვერდი /unseal ორ შემთხვევაში ჩნდება. სანამ ის ღიაა, კონსოლი და სერვერებთან კავშირები მიუწვდომელია.

The gateway is sealed

თქვენ აირჩიეთ რეჟიმი Sealed with a passphrase, და სერვისი გადაიტვირთა (სერვერის გადატვირთვა, პაკეტის განახლება, systemctl restart). შეიყვანეთ Passphrase და დააჭირეთ Unseal. კარიბჭე გაიხსნება და ყველა მსმენელს გაუშვებს (SSH, RDP, VNC, მონაცემთა ბაზები).

თუ ფრაზა დაგავიწყდათ, დააჭირეთ Recover with the recovery key: შეიყვანეთ Recovery key, მიუთითეთ New passphrase და Repeat the passphrase, დააჭირეთ Recover and unseal.

The encryption key is unavailable

რეჟიმი «დაცულია ოპერაციული სისტემით», მაგრამ გასაღების ფაილი არ არის ან ამ ბაზას არ შეესაბამება (მაგალითად, ბაზა აღადგინეს ახალ სერვერზე კატალოგ /var/lib/bursu-pam/keys-ის გარეშე). შეიყვანეთ აღდგენის გასაღები და დააჭირეთ Recover the key. თუ აღდგენის შემდეგ კარიბჭე წერს The key was recovered და გასაღებების კატალოგის პრობლემებს ჩამოთვლის — გამოასწორეთ ისინი სერვისის შემდეგ გადატვირთვამდე; აღდგენის გასაღები ძალაში რჩება.

ერთი მისამართიდან წუთში არაუმეტეს 5 მცდელობისა; ყოველი მცდელობა, წარმატებული თუ არა, აუდიტის ჟურნალში იწერება. შეცდომები: The passphrase did not match., The recovery key did not match.

ლიცენზია

კარიბჭე ლიცენზირდება აქტიური სერვერების რაოდენობის მიხედვით (კონსოლში ჩართული სერვერები); მომხმარებლების რაოდენობა შეზღუდული არ არის. ლიცენზია — BURSUsofts-ის მიერ ხელმოწერილი ფაილია (.bpl), რომელსაც კარიბჭე თავად ამოწმებს, ინტერნეტთან კავშირის გარეშე. ის მიბმულია ინსტალაციაზე (Installation ID) და ამ სერვერზე (ანაბეჭდი /etc/machine-id-ის საფუძველზე).

გვერდი: Settings → Licence (/system/licence), მხოლოდ Administrator-ისთვის. ის ლიცენზიის ნებისმიერ მდგომარეობაში მუშაობს. მასზე ყოველი მოქმედება ახალ დადასტურებას მოითხოვს: კარიბჭემ შეიძლება კიდევ ერთხელ გკითხოთ პაროლი და კოდი (You may be asked for your password and code again first.).

ბარათი Status

მდგომარეობები (ნიშნული ბარათის კუთხეში): No licence, Trial, Active, Ends soon (ფასიან ლიცენზიას — დასრულებამდე 7 დღე და ნაკლები), In grace (მხოლოდ ფასიანს), Ended, Activated on another host, Released.

საცდელი ლიცენზია 7 დღით

საცდელი ლიცენზია ყველა ფუნქციას იძლევა 7 დღით და 25 აქტიურ სერვერამდე; მის შემდეგ საშეღავათო ვადა არ არის. ერთი ინსტალაციისთვის საცდელი ლიცენზიის მიღება ერთხელ შეიძლება; პორტალის პირობებით — ასევე ერთი საცდელი ლიცენზია ორგანიზაციაზე (ოფლაინ-საცდელი გაიცემა bursucm.com-ის ანგარიშით). ნიშნული Ends soon საცდელ ლიცენზიას არ აქვს: ის ბოლო დღემდე აჩვენებს Trial-ს, შემდეგ კი მაშინვე Ended-ს, ამიტომ მისი დასრულების თარიღი წინასწარ ჩაიწერეთ.

ინტერნეტით — ერთი ღილაკი

1. ბლოკში Online — one call per click დააჭირეთ Start the 7-day trial online.
2. ფანჯარა აჩვენებს, ზუსტად რა გაიგზავნება (What is sent): ინსტალაციის იდენტიფიკატორი, სერვერის ანაბეჭდი, კარიბჭის ვერსია, აქტიური სერვერების რაოდენობა, კარიბჭის დრო, როდის დასრულდა დაყენება, ერთჯერადი რიცხვი, ლიცენზიის რიგითი ნომერი და კარიბჭის ღია გასაღები — კარიბჭის ხელმოწერით. არანაირი სახელები, მისამართები და ორგანიზაციის მონაცემები.
3. დააჭირეთ Send this one call. რამდენიმე წამში: The 7-day trial licence is installed.

კარიბჭე bursucm.com-ს მიმართავს მხოლოდ მაშინ, როცა ღილაკს დააჭერთ; დანარჩენ დროს ის არაფერს აგზავნის. თუ ინტერნეტთან წვდომა მხოლოდ პროქსით არის — მიუთითეთ ის ბლოკში Proxy server (იხ. ქვემოთ).

ინტერნეტის გარეშე — მოთხოვნის კოდი

1. ბლოკში Request codes (offline) დააჭირეთ Start the 7-day trial, შემდეგ Make the request code.
2. კარიბჭე აჩვენებს Request code-ს და მის QR-კოდს (შეიძლება Download as .txt). კოდს პორტალი ერთხელ იღებს; კარიბჭემ მოთხოვნა დაიმახსოვრა — სანამ პასუხი არ არის, გვერდზე ჩანს Waiting for an answer: ….
3. ინტერნეტთან დაკავშირებული ნებისმიერი კომპიუტერიდან შედით https://bursucm.com/pam/activate-ზე (საჭიროა bursucm.com-ის ანგარიში), ჩასვით კოდი (ან დაასკანერეთ QR ტელეფონით) და მიიღეთ ლიცენზიის ფაილი .bpl.
4. გადაიტანეთ ფაილი დახურულ ქსელში და დააყენეთ: Install a licence → Licence file (ან ჩასვით ტექსტი Or paste the licence-ში) → Install. მზადაა: The licence was installed.

ფასიანი ლიცენზია

შეძენისას იღებთ გააქტიურების გასაღებს სახით BPK- და 20 სიმბოლო. კონკრეტული ინსტალაციისთვის ლიცენზიის შესაძენად გამყიდველს შეიძლება დასჭირდეს ამ ინსტალაციის Claim code (ბლოკი Claim code გვერდზე): ის ინსტალაციას bursucm.com/pam/licences-ზე თქვენს ორგანიზაციაზე მიაბამს. ბლოკი ჩანს, სანამ საცდელი ლიცენზია მოქმედებს (ან ლიცენზია ორგანიზაციის სახელის გარეშე); ორგანიზაციის სახელიანი ფასიანი ლიცენზიის შემდეგ კოდი ავიწყდება და ბლოკი აღარ ჩანს. თავად საცდელი პერიოდისთვის კოდი საჭირო არ არის. შეინახეთ claim code საიდუმლოდ — ნებისმიერს, ვისაც ის აქვს, შეუძლია ინსტალაცია საკუთარ თავზე მიაბას.

• ონლაინ: Activate with an activation key → შეიყვანეთ Activation key → Send this one call → The licence from your activation is installed.
• ოფლაინ: Activate a paid licence → Make the request code → კოდი შეიყვანება https://bursucm.com/pam/activate-ზე, სადაც ირჩევთ ფასიან უფლებას (entitlement) → მიღებული ფაილი დგება Install a licence-ით.
• მზა ფაილი. თუ BURSUsofts-მა ფაილი .bpl გამოგიგზავნათ, უბრალოდ დააყენეთ ის Install a licence-ით. იკითხება მხოლოდ ბლოკი BEGIN და END სტრიქონებს შორის, ხელმოწერა მოწმდება.

გაგრძელება და ყოველდღიური შემოწმება

ახალ ლიცენზიას (გაგრძელება, მეტი სერვერი) ასევე აყენებენ: ფაილით, ონლაინ-ღილაკით Check now (ერთი მიმართვა — მზა ლიცენზიის წამოღება, თუ ის არსებობს) ან Background check-in-ის ჩართვით: Turn the background check-in on — კარიბჭე დღეში ერთხელ თავად ეკითხება bursucm.com-ს გაგრძელებების შესახებ. ნაგულისხმევად შემოწმება გამორთულია. თუ ის ზედიზედ ერთი კვირა ვერ ხერხდება, ზარში გაფრთხილება გამოჩნდება.

ავტომატურად მიღებული ლიცენზია, რომელიც მოქმედზე უარესია (ნაკლები სერვერი, უფრო მოკლე ვადა, უფრო მოკლე საშეღავათო ვადა, ნაკლები ჰოსტ-სერვერი, ამ სერვერს არ მოიცავს), თავისით არ დგება: გვერდი გეტყვით The licence … was received but not installed, because it … — დააყენეთ ის ხელით, თუ მართლა გჭირდებათ.

პროქსი

თუ კარიბჭე ინტერნეტში მხოლოდ HTTP-პროქსით გადის, შეიყვანეთ ის Proxy address (empty = the system's setting)-ში, მაგალითად http://proxy.example.org:3128, და დააჭირეთ Save the proxy. Use the system default — სისტემური პარამეტრის დაბრუნება. ლოგინითა და პაროლით პროქსი მხარდაჭერილი არ არის; მისამართი — მხოლოდ http://ჰოსტი:პორტი ან https://ჰოსტი:პორტი.

სხვა სერვერზე გადატანა

ლიცენზია სერვერზეა მიბმული. თუ კარიბჭე გადაიტანეთ (ასლიდან ახალ მანქანაზე აღადგინეთ), მდგომარეობა გახდება Activated on another host. ფასიანი ლიცენზიისთვის მოქმედებს გადასვლის საშეღავათო ვადა — არანაკლებ 14 დღისა (ან მეტი, თუ ლიცენზიაში ასეა ჩაწერილი), რომლის განმავლობაშიც ყველაფერი მუშაობს; გვერდი აჩვენებს, რამდენი დღეა გამოყენებული. ამ დროში გადაიტანეთ ლიცენზია: Move the licence to this host online (ერთი მიმართვა) ან ოფლაინ-კოდით Move the licence to this host. გადატანების რაოდენობა ლიცენზიის პირობებით არის შეზღუდული. საშეღავათო ვადის დასრულების შემდეგ ახალი სეანსები და ცვლილებები უარყოფილია.

ინსტალაციის გათავისუფლება

კარიბჭის ექსპლუატაციიდან გამოყვანამდე გაათავისუფლეთ ლიცენზია, რომ ის სხვა სერვერზე გააქტიუროთ: Release… → დასადასტურებლად შეიყვანეთ მოქმედი ლიცენზიის სერიული ნომერი → ერთ-ერთი ვარიანტი:

• Release and show the release code — კარიბჭე არაფერს აგზავნის და აჩვენებს Release code-ს, რომელსაც პორტალზე თავად შეიყვანთ. კოდი ჩანს მხოლოდ ერთხელ — დააკოპირეთ ის, სანამ გვერდს დატოვებთ.
• Release and tell bursucm.com now (one call) — გათავისუფლების შესახებ პორტალს მაშინვე ეცნობება, კოდი საჭირო არ არის.

როცა ლიცენზიას ვადა გასდის: რა ჩერდება და რა მუშაობს

ლიცენზიის ვადის გასვლა — ეს «რბილი გაჩერებაა» და არა გამორთვა. ფასიან ლიცენზიას დასრულებამდე 7 დღით ადრე უჩნდება ნიშნული Ends soon და გაფრთხილება ზარში; დასრულების შემდეგ მოქმედებს საშეღავათო ვადა (In grace, მისი ხანგრძლივობა ლიცენზიაშია ჩაწერილი), როცა ყველაფერი ჯერ კიდევ მუშაობს. საცდელ ლიცენზიას არც ნიშნული აქვს, არც გაფრთხილება და არც საშეღავათო ვადა: Trial ბოლო დღემდე, შემდეგ კი მაშინვე Ended. დასრულების შემდეგ (და ფასიანი ლიცენზიის საშეღავათო ვადის შემდეგ):

თუ ჩართულია იმაზე მეტი სერვერი, ვიდრე ლიცენზია უშვებს, საშეღავათო ვადის შემდეგ სეანსები დაიშვება მხოლოდ ლიმიტის ფარგლებში მყოფ სერვერებთან, ცვლილებები კი უარყოფილია, სანამ ზედმეტი სერვერები არ გამოირთვება. ლიმიტზე მეტი სერვერის ჩართვა მაშინვე შეუძლებელია: The licence allows … active servers. Switch off a server or extend the licence.

კარიბჭე საკუთარ დროს არ ენდობა

კარიბჭე თვალყურს ადევნებს, რომ ლიცენზიის გაგრძელება საათის გადაწევით ან ბაზის უკან დაბრუნებით შეუძლებელი იყოს. თუ ლიცენზიის მდგომარეობის ფაილი /var/lib/bursu-pam/licence-state.json გაქრა ან დაზიანდა და ამავდროულად აუდიტის ჟურნალში ხელმოწერილი დროის ნიშნული არ ემთხვევა, თუ ბაზა მდგომარეობის ფაილზე ძველი აღმოჩნდა (ძველი ასლიდან აღდგენილი), ან ჟურნალიდან სტრიქონები გაქრა, გვერდი წერს The gateway cannot trust its own time: ახალი სეანსები და ცვლილებები უარყოფილია, გადატვირთვა არ შველის. გამოსავალი ერთია — ლიცენზია, რომელიც გაცემულია ამ მდგომარეობის დაწყების შემდეგ შექმნილ მოთხოვნაზე პასუხად:

• თუ ფასიანი ლიცენზია მოქმედებს — Request a support licence (ოფლაინ-კოდი ან ონლაინ-ღილაკი) და მისი გაგზავნა BURSUsofts-ში;
• წინააღმდეგ შემთხვევაში — გააქტიურების მოთხოვნა (Activate a paid licence); საცდელი ლიცენზია ამ მდგომარეობიდან ვერ გამოიყვანს.

თუ კარიბჭის საათი წინ წავიდა, შეიძლება გამოჩნდეს ღილაკი Re-base the licence to this gateway's time — ის ლიცენზიებს კარიბჭის მიმდინარე დროზე გადაითვლის. ამიტომ ბაზა აღადგინეთ ერთად კატალოგ /var/lib/bursu-pam-თან ერთი და იმავე ასლიდან (იხ. «სარეზერვო კოპირება»).

Licences received

ყველა მიღებული ლიცენზიის ცხრილი: Serial, Seq, Kind, Servers, Term, Received (როგორ არის მიღებული — uploaded, online, check-in, restored from the state file; ვის მიერ და როდის) და Status — In force, Pending, Superseded, Released, Ended.

ლიცენზიის გვერდის ყველა შეტყობინება და რა უნდა გააკეთოთ მათთან — თავში «გაუმართაობები → ლიცენზია».

ფაილი gateway.json

/etc/bursu-pam/gateway.json ინახავს მხოლოდ იმას, რაც კარიბჭემ ბაზასთან დაკავშირებამდე უნდა იცოდეს: სად არის ბაზა, რომელ მისამართებსა და პორტებზე უსმინოს, სად არის სერტიფიკატი და კატალოგები. დანარჩენი ყველაფერი კონსოლში კონფიგურირდება და ბაზაში ინახება. ფაილს ქმნის bursu-pam-setup, მასში პორტებს ცვლის bursu-pam-configure; ხელით მას მხოლოდ იმ პარამეტრებისთვის არედაქტირებენ, რომლებიც ოსტატში არ არის.

• ფორმატი — JSON; კარიბჭე უშვებს კომენტარებს // და ბოლო მძიმეებს, მაგრამ bursu-pam-configure და bursu-pam-check მხოლოდ სუფთა JSON-ს კითხულობენ — ნუ დაამატებთ კომენტარებს, თუ ოსტატით სარგებლობთ.
• უცნობ პარამეტრს კარიბჭე უარყოფს და არ ეშვება — ასე ბეჭდვითი შეცდომა ჩუმად ნაგულისხმევ მნიშვნელობად არ იქცევა. პარამეტრების სახელები რეგისტრისადმი მგრძნობიარე არ არის.
• უფლებები: root:bursu-pam 0640 (ფაილი შეიძლება ბაზის პაროლს შეიცავდეს). ამოწმებს bursu-pam-check.
• რედაქტირების შემდეგ: sudo systemctl restart bursu-pam-gateway (მიმდინარე სეანსები შეწყდება). თუ კარიბჭე არ ამუშავდა — journalctl -u bursu-pam-gateway -n 50 არასწორ პარამეტრს დაასახელებს.
• მაგალითი კომენტარებით: /usr/share/doc/bursu-pam/gateway.json.example.

ფაილი, რომელსაც ინსტალაცია ქმნის:

{
  "connectionString": "Host=/var/run/postgresql;Port=5432;Database=bursu_pam;Username=bursu-pam",
  "listenUrl": "https://0.0.0.0:443",
  "dataDirectory": "/var/lib/bursu-pam",
  "keyDirectory": "/var/lib/bursu-pam/keys",
  "sshListen": "0.0.0.0:2222",
  "rdpWorkerPath": "/opt/bursu-pam/workers/RdpWorker",
  "vncWorkerPath": "/opt/bursu-pam/workers/bursu-pam-vnc",
  "vncLauncherPath": "/opt/bursu-pam/workers/bursu-pam-vnc-launch"
}

პარამეტრები

კარიბჭის სერტიფიკატი

ერთი სერტიფიკატი ემსახურება კონსოლს (HTTPS) და კარიბჭის ყველა TLS-მსმენელს (VNC TLS-ით, ბაზების მსმენელები). BURSUcm-ის კლიენტები კარიბჭის სერტიფიკატს პირველი დაკავშირებისას იმახსოვრებენ (ამაგრებენ) და დადასტურებას კვლავ ითხოვენ, თუ ის შეიცვალა.

თვითხელმოწერილი სერტიფიკატი

თუ certificatePath არ არის მითითებული, პირველი გაშვებისას კარიბჭე ქმნის /var/lib/bursu-pam/gateway.pfx-ს: ECDSA P-256, SHA-256, სახელი CN=<მანქანის სახელი>, ვადა ორი წელი; თუ VNC ჩართულია, მას ემატება vncAdvertisedName. ბრაუზერები ასეთ სერტიფიკატზე გაფრთხილებას იძლევიან — ეს მოსალოდნელია; შეამოწმეთ ანაბეჭდი და გააგრძელეთ. მუდმივი მუშაობისთვის უმჯობესია თქვენი სერტიფიკაციის ცენტრის სერტიფიკატი.

შექმნილ ფაილს კარიბჭე შემდეგ მხოლოდ კითხულობს: ის ორი წლის გასვლის შემდეგ სერტიფიკატს არ აგრძელებს და მასში VNC-ის სახელს არ ამატებს, თუ VNC მოგვიანებით ჩართეს. ვადა ჩანს Settings → Status-ზე. ახალი თვითხელმოწერილი სერტიფიკატის მისაღებად (ვადის გასვლის ან VNC-ის ჩართვის შემდეგ) ძველი ფაილი განზე გადადეთ და სერვისი გადატვირთეთ — კარიბჭე ახალს შექმნის:

sudo mv /var/lib/bursu-pam/gateway.pfx /var/lib/bursu-pam/gateway.pfx.old
sudo systemctl restart bursu-pam-gateway

BURSUcm-ის მომხმარებლები ახალ სერტიფიკატს დაინახავენ და მას ერთხელ დაადასტურებენ.

საკუთარი სერტიფიკატი

1. გამოუშვით სერტიფიკატი კარიბჭის სახელზე (მაგალითად pam.example.org; თუ მომხმარებლები IP-ითაც შედიან — დაამატეთ IP ალტერნატიულ სახელებში). თუ VNC ჩართულია — მასში აუცილებლად უნდა იყოს სახელი vncAdvertisedName-დან.
2. განათავსეთ ფაილები ისე, რომ bursu-pam-მა შეძლოს მათი წაკითხვა, სხვა მომხმარებლებმა კი — არა. კატალოგი /etc/bursu-pam სერვისისთვის მხოლოდ წასაკითხია — ეს გამოდგება: ფაილი უკვე უნდა არსებობდეს.

   sudo install -d -o root -g bursu-pam -m 0750 /etc/bursu-pam/tls
   sudo install -o root -g bursu-pam -m 0640 gateway.pfx /etc/bursu-pam/tls/gateway.pfx

3. დაამატეთ gateway.json-ში PKCS#12-ის ვარიანტი:

   "certificatePath": "/etc/bursu-pam/tls/gateway.pfx",
   "certificatePassword": "ფაილის-პაროლი"

   ან PEM:

   "certificatePath": "/etc/bursu-pam/tls/gateway.crt",
   "certificateKeyPath": "/etc/bursu-pam/tls/gateway.key"

   (certificatePassword — მხოლოდ თუ გასაღები დაშიფრულია). კარიბჭე .crt-დან (და .pfx-დან) კითხულობს მხოლოდ პირველ სერტიფიკატს — საკუთარს, დახურული გასაღებით; ფაილიდან ჯაჭვს ის არ აწყობს და კლიენტებს არ გადასცემს. ამიტომ კლიენტები შუალედურ სერტიფიკაციის ცენტრს თავად უნდა ენდობოდნენ (მაგალითად, გაავრცელეთ ის სამუშაო ადგილებზე ჯგუფური პოლიტიკით ან სანდო სერტიფიკატების პაკეტით).
4. sudo systemctl restart bursu-pam-gateway და გახსენით კონსოლი — ბრაუზერმა თქვენი სერტიფიკატი უნდა აჩვენოს. BURSUcm-ის მომხმარებლები გააფრთხილეთ: კლიენტი ახალი სერტიფიკატის დადასტურებას ერთხელ მოითხოვს.

გაგრძელება: შეცვალეთ ფაილი იმავე გზაზე და გადატვირთეთ სერვისი.

ქსელი და ფაიერვოლი

პაკეტი და ოსტატი სერვერის ფაიერვოლს არასოდეს ცვლიან. პორტები თავად გახსენით.

ufw

თუ ufw ჩართულია (sudo ufw status → Status: active), bursu-pam-configure არჩეული პორტებისთვის მზა ბრძანებებს ბეჭდავს. ტიპური ნაკრები:

sudo ufw allow 443/tcp      # კონსოლი და BURSUcm-ის კლიენტები
sudo ufw allow 2222/tcp     # SSH, SFTP, SCP, Telnet-მოწყობილობები
sudo ufw allow 3389/tcp     # RDP (თუ ჩართულია)
sudo ufw allow 5900/tcp     # VNC (თუ ჩართულია)
sudo ufw allow 15432/tcp    # PostgreSQL-ის მსმენელი   (თუ ჩართულია)

უმჯობესია წყაროები მომხმარებლების ქსელით შეზღუდოთ: sudo ufw allow from 10.20.0.0/16 to any port 2222 proto tcp. ufw-ის ჩართვამდე არ დაგავიწყდეთ, დატოვოთ წვდომა პორტ 22-ზე თავად სერვერის ადმინისტრირებისთვის (sudo ufw allow 22/tcp).

სამიზნე სერვერები

სამიზნე სერვერებზე სამსახურებრივი პორტები დაუშვით მხოლოდ კარიბჭის მისამართიდან. მაგალითი Linux-ისთვის ufw-ით: sudo ufw allow from 192.0.2.10 to any port 22 proto tcp და აკრძალვა დანარჩენებისთვის; Windows-ისთვის — Windows-ის ფაიერვოლის წესი RDP-სთვის (3389) კარიბჭის დისტანციური მისამართით. იგივე გააკეთეთ VNC-ის, Telnet-ისა და ბაზების პორტებისთვის.

უკუპროქსი და NAT

თუ კონსოლის წინ უკუპროქსი დგას, ჩაწერეთ მისი მისამართი trustedProxies-ში. თუ კარიბჭე NAT-ით ან პორტების გადამისამართებით არის გამოქვეყნებული, მიუთითეთ გარე მისამართები sshPublicHost/sshPublicPort-ში, rdpPublicHost/rdpPublicPort-სა და dbPublicHost-ში — მათ კარიბჭე კლიენტებს აცნობებს.

ტექნიკური მომსახურება

სერვისი და ჟურნალები

systemctl status bursu-pam-gateway            # მუშაობს თუ არა
sudo systemctl restart bursu-pam-gateway      # გადატვირთვა (სეანსები წყდება; დალუქულ რეჟიმში — ისევ /unseal)
journalctl -u bursu-pam-gateway -n 100        # ჟურნალის ბოლო სტრიქონები
journalctl -u bursu-pam-gateway -f            # ჟურნალი რეალურ დროში
journalctl -u bursu-pam-gateway --since today

სერვისის ჟურნალი არ შეიცავს პაროლებს, დაყენების კოდებსა და კავშირის სტრიქონებს. აუდიტის ჟურნალი (ვინ რა გააკეთა) — კონსოლშია, იხ. «აუდიტის ჟურნალი».

ჰოსტის შემოწმება: bursu-pam-check

sudo bursu-pam-check            # თითო სტრიქონი თითო შემოწმებაზე: OK, WARN ან FAIL
sudo bursu-pam-check --quiet    # მხოლოდ WARN და FAIL

მხოლოდ კითხულობს, არაფერს ცვლის და ქსელს არ მიმართავს. დასრულების კოდი 1, თუ ერთი FAIL მაინც არის. გაუშვით root-ის სახელით — თორემ შემოწმებების ნაწილი არ შესრულდება.

განახლება

sudo apt install ./bursu-pam_<ახალი ვერსია>_amd64.deb

1. პაკეტი კარიბჭეს აჩერებს (ყველა სეანსი წყდება) — განახლება მომსახურების ფანჯარაში ჩაატარეთ და მომხმარებლები წინასწარ გააფრთხილეთ.
2. ფაილების ჩანაცვლებამდე ქმნის ბაზის ასლს: /var/backups/bursu-pam/pre-upgrade-<ძველი ვერსია>-<დრო>.dump (ინახება ბოლო ორი). საჭიროა თავისუფალი ადგილი — ბაზის ზომაზე ორჯერ მეტი, თორემ განახლება ჩერდება და ორივე რიცხვს ასახელებს.
3. თუ ასლის შექმნა ვერ მოხერხდა (ადგილი არ არის, ბაზა მიუწვდომელია) ან კარიბჭე არ გაჩერდა, განახლება უქმდება: დაინახავთ სტრიქონს NOT upgrading - …, dpkg-ის შეცდომას, ძველი ვერსია კი ისევ გაშვებულია.
4. ახალი ვერსია გაშვებისას ბაზის სქემას ანახლებს. gateway.json და მონაცემები ხელუხლებელი რჩება; განახლებისას კითხვები პორტების შესახებ არ ისმება.
5. დალუქულ რეჟიმში განახლების შემდეგ გახსენით /unseal.

დისტანციური ბაზისთვის პაკეტი ასლს არ ქმნის (ამის შესახებ ერთი სტრიქონით წერს) — ასლი განახლებამდე თავად შექმენით.

წინა ვერსიაზე დაბრუნება

მხოლოდ იმავე სერვერზე მდებარე ბაზისთვის. ყველაფერი, რაც განახლების შემდეგ ჩაიწერა, დაიკარგება — ჯერ ასლის ფაილი სხვა ადგილას დააკოპირეთ.

კატალოგი /var/backups/bursu-pam და ასლის ფაილი root-ს ეკუთვნის და სხვებისთვის დახურულია, გადამისამართებას < კი იმის გარსი ასრულებს, ვინც ბრძანებას კრეფს, და არა sudo. ამიტომ ბლოკი root-ის სახელით შეასრულეთ: ჯერ sudo -i, შემდეგ ბრძანებები sudo-ს გარეშე.

sudo -i
systemctl stop bursu-pam-gateway
runuser -u postgres -- psql -c 'DROP DATABASE bursu_pam'
bursu-pam-setup                                    # ქმნის ცარიელ bursu_pam-ს მფლობელით bursu-pam
runuser -u bursu-pam -- env -i PATH=/usr/sbin:/usr/bin:/sbin:/bin \
    pg_restore -h /var/run/postgresql -d bursu_pam --exit-on-error < /var/backups/bursu-pam/pre-upgrade-<ძველი>-<დრო>.dump
apt-get install -y --allow-downgrades /გზა/ფაილამდე/bursu-pam_<ძველი ვერსია>_amd64.deb
exit                                               # თქვენს გარსში დაბრუნება

სარეზერვო კოპირება და აღდგენა

აღდგენისთვის საჭიროა სამი რამ, და სამივე სავალდებულოა:

1. ბაზა bursu_pam — კატალოგი, მომხმარებლები, წესები, აუდიტის ჟურნალი;
2. კატალოგი /var/lib/bursu-pam — მთავარი გასაღები (keys/), სეანსების ჩანაწერები, ლიცენზიის მდგომარეობა, სერტიფიკატი;
3. აღდგენის გასაღები ოსტატ /setup-იდან — ქსელის გარეშე, სეიფში, არასოდეს ამ სერვერზე.

(   # ქვეგარსი: umask თქვენს გარსში არ დარჩება
  umask 077
  sudo runuser -u bursu-pam -- pg_dump -Fc -h /var/run/postgresql bursu_pam > bursu_pam.dump
  sudo tar -C /var/lib -czf bursu-pam-data.tar.gz bursu-pam
)

არქივი გასაღებებს შეიცავს — შეინახეთ ის ისეთივე საიმედოდ, როგორც თავად გასაღებები, ბაზის ასლისგან ცალკე. keys/-დან მთავარი გასაღების გარეშე ბაზის ასლიდან ვერც საიდუმლოებები წაიკითხება და ვერც ჩანაწერები; ბაზის ასლი მონაცემთა კატალოგის გარეშე უსარგებლოა. ორივე ნაწილი ერთდროულად შექმენით: ბაზა, რომელიც ლიცენზიის მდგომარეობის ფაილზე უფრო ძველი ასლიდან არის აღდგენილი, კარიბჭეს გადაიყვანს მდგომარეობაში «საკუთარ დროს არ ენდობა» (იხ. «ლიცენზია»).

ახალ სერვერზე აღდგენა: დააყენეთ იგივე პაკეტი, გააჩერეთ სერვისი, აღადგინეთ ბაზა (DROP DATABASE, bursu-pam-setup, pg_restore — როგორც ზემოთ, უკან დაბრუნებისას), გაშალეთ არქივი /var/lib-ში (მფლობელი bursu-pam), გაუშვით სერვისი. თუ გასაღების ფაილი არ არის ან არ შეესაბამება, კარიბჭე გახსნის გვერდს /unseal აღდგენის გასაღებისთვის. შემდეგ ლიცენზია ახალ სერვერზე უნდა გადაიტანოთ («გადატანა»).

ჩანაწერები სხვა დისკზე

სერვისს ჩაწერა მხოლოდ /var/lib/bursu-pam-ში შეუძლია. ჩანაწერების ცალკე დისკზე შესანახად:

sudo install -d -o bursu-pam -g bursu-pam -m 0700 /srv/pam-recordings
sudo systemctl edit bursu-pam-gateway
#   [Service]
#   ReadWritePaths=/srv/pam-recordings
# gateway.json-ში:  "recordingsDirectory": "/srv/pam-recordings"
sudo systemctl restart bursu-pam-gateway

ან უფრო მარტივად — ცალკე დისკი პირდაპირ /var/lib/bursu-pam/recordings-ში მიამაგრეთ.

Ubuntu-ს განახლებები და გადატვირთვები

პაკეტი ათავსებს /etc/needrestart/conf.d/bursu-pam.conf-ს, რომ უტილიტა needrestart apt upgrade-ის შემდეგ კარიბჭეს თავისით არ გადატვირთავდეს (გადატვირთვა ყველა სეანსს წყვეტს). ბიბლიოთეკების განახლების შემდეგ sudo needrestart -b კარიბჭეს გადატვირთვის მომლოდინედ აჩვენებს — გადატვირთეთ ის მომსახურების ფანჯარაში.

წაშლა

sudo apt remove bursu-pam     # აჩერებს სერვისს, შლის მხოლოდ პაკეტის ფაილებს
sudo apt purge bursu-pam      # იგივე, პლუს სერვისის მდგომარეობა; მეტი არაფერი

არც remove და არც purge არ შლის /var/lib/bursu-pam-ს (გასაღებები და ჩანაწერები), /etc/bursu-pam-ს, /var/backups/bursu-pam-ს, ბაზას bursu_pam, როლსა და ანგარიშს bursu-pam — ხელახალი ინსტალაცია მათ აიყვანს. საბოლოო წაშლა შეუქცევადია; შეასრულეთ ის მხოლოდ მას შემდეგ, რაც დარწმუნდებით, რომ ჩანაწერები და გასაღებები აღარავის სჭირდება:

sudo runuser -u postgres -- psql -c 'DROP DATABASE bursu_pam'
sudo runuser -u postgres -- psql -c 'DROP ROLE "bursu-pam"'
sudo rm -r /var/lib/bursu-pam /etc/bursu-pam /var/backups/bursu-pam
sudo deluser --system bursu-pam

ექსპლუატაციიდან გამოყვანამდე გაათავისუფლეთ ლიცენზია («ინსტალაციის გათავისუფლება»).

ვებ-კონსოლი

კონსოლი თავად კარიბჭის ვებ-გვერდებია. მასში ადმინისტრატორი ამატებს მომხმარებლებს, სერვერებსა და წვდომის წესებს, აუდიტორი კითხულობს ჟურნალებს, დამმტკიცებელი იღებს გადაწყვეტილებებს მოთხოვნებზე, ხოლო ჩვეულებრივი მომხმარებელი ხედავს, რაზე აქვს წვდომა. კონსოლი ბრაუზერში იხსნება კარიბჭის მისამართზე; მისამართი და სერტიფიკატი ინსტალაციისას ისაზღვრება (იხ. განყოფილებები ქსელი და პორტები და კარიბჭის სერტიფიკატი). კონსოლი JavaScript-ის გარეშეც მუშაობს. ყოველი ფორმა დაცულია მოთხოვნის გაყალბებისგან, გვერდები ბრაუზერის ქეშში არ ინახება.

რას ხედავს ადამიანი კონსოლში, მის როლებზეა დამოკიდებული. როლები აღწერილია განყოფილებაში როლები; მენიუს პუნქტები, რომელთა გახსნაც როლს არ შეუძლია, საერთოდ არ ჩანს (ისინი «ნაცრისფერი» კი არ არის, არამედ დამალულია).

შესვლა: გვერდი «Sign in to the console»

გვერდის მისამართია /signin. მასზე ხვდება ყველა, ვინც კონსოლი მოქმედი სეანსის გარეშე გახსნა. თუ მანამდე კონკრეტული გვერდის გახსნა სურდა, შესვლის შემდეგ კარიბჭე სწორედ იმ გვერდზე დააბრუნებს.

ფორმის ზემოთ შეიძლება ბანერი იყოს: ტექსტი, რომელიც ადმინისტრატორმა პარამეტრში Banner text მიუთითა (Sign-in and MFA). ჩვეულებრივ მასში წერენ გაფრთხილებას, რომ მუშაობა კონტროლის ქვეშ მიმდინარეობს.

შესვლის შეცდომებზე კარიბჭე ერთი და იმავე ფრაზით პასუხობს, რომ პასუხით ვერ გაიგოთ, არსებობს თუ არა ასეთი ლოგინი: Incorrect login or password. ასე პასუხობს არასწორ პაროლზეც, უცნობ ლოგინზეც, გათიშულ მომხმარებელზეც და ადამიანზეც, რომელიც დირექტორიის არცერთ შესაბამის ჯგუფში არ არის. გამონაკლისია დაბლოკვა: Account temporarily locked until {0}. (დრო კარიბჭის სასაათო სარტყელში). შესვლის შეცდომების ყველა ტექსტი თავმოყრილია თავში «გაუმართაობები».

შესვლის ნაბიჯები და გვერდების თანმიმდევრობა

შესვლა რამდენიმე ნაბიჯისგან შედგება. ყოველი შემდეგი ნაბიჯი მხოლოდ მაშინ ჩანს, როცა საჭიროა.

საწყისი გვერდი: ადმინისტრატორი და აუდიტორი ხვდებიან Overview-ზე (თუ კარიბჭე ჯერ ლიცენზირებული არ არის, ადმინისტრატორი ჯერ გვერდზე Licence ხვდება); დამმტკიცებელი — Approvals-ზე; ყველა დანარჩენი — My profile-ზე.

სანამ ადამიანი ყველა ნაბიჯს არ გაივლის, კარიბჭე მას არსად უშვებს, გარდა მიმდინარე ნაბიჯის გვერდისა. ნებისმიერი სხვა გვერდი მას ამ ნაბიჯზე აბრუნებს.

კოდი აპიდან: გვერდი «Two-factor sign-in»

მისამართია /signin/totp. სათაურის ქვეშ წერია ლოგინი, რომლითაც შესვლა მიმდინარეობს. გვერდზე:

• ექვსი უჯრა 6-digit code (ციფრების აკრეფა შეიძლება ზედიზედ ან მთლიანად ჩასმა), მინიშნება «Enter the 6-digit code from the authenticator app.» და ღილაკი Confirm;
• ბმული Enter a recovery code: გვერდი გადაირთვება ველზე Recovery code (ნიმუში xxxxx-xxxxx) და ტექსტზე «Enter one of your recovery codes. Each code works once.»; უკან აბრუნებს ბმული Enter a code from the app;
• ღილაკი Sign in as another user: ასრულებს დაწყებულ შესვლას და შესვლის გვერდზე აბრუნებს.

კოდი ექვსნიშნაა, ავთენტიფიკატორის აპიდან (RFC 6238: SHA-1, 6 ციფრი, ბიჯი 30 წამი). ერთი და იმავე კოდის ორჯერ გამოყენება არ შეიძლება. თუ კოდი არ გამოდგა, გვერდი წერს The code did not match. შეამოწმეთ, რომ ტელეფონზე დრო ზუსტია.

დროებითი პაროლის შეცვლა: გვერდი «Choose your password»

მისამართია /signin/password. ჩანს ადამიანისთვის, რომელსაც პაროლი ადმინისტრატორმა გასცა. ტექსტი: «The administrator gave you a temporary password. Choose your own to continue.» ველები:

თუ ძალიან მოკლეა: The password must be at least N characters long. სიგრძე Unicode-ის სტანდარტული ნორმალიზაციის შემდეგ სიმბოლოებში ითვლება.

დირექტორიის (დომენის) მომხმარებელს ეს გვერდი ფორმის ნაცვლად აჩვენებს სათაურს Change your domain password (LDAP-ისთვის — Change your directory password), ტექსტს იმის შესახებ, სად შეიცვალოს პაროლი, და ერთადერთ ღილაკს Sign out. კარიბჭე დირექტორიაში არასოდეს წერს, ამიტომ პაროლი მხოლოდ თავად დირექტორიის საშუალებებით იცვლება.

TOTP-ის დაყენება: გვერდი «Set up two-factor sign-in»

მისამართია /signin/enrol. კონსოლში შესვლა დაცულია მეორე ფაქტორით — ტელეფონის აპიდან მიღებული კოდით. გვერდი ჩანს ადამიანისთვის, რომელსაც ის ჯერ არ აქვს, თუ პარამეტრი Require TOTP ჩართულია (ნაგულისხმევად ჩართულია). ნაბიჯები:

1. დაასკანერეთ კოდი. ბლოკში 1. Scan the code in the authenticator app ნაჩვენებია QR-კოდი. თუ დასასკანერებელი არაფერი გაქვთ, შეიყვანეთ გასაღები ხელით: ის ნაჩვენებია წარწერის «Or enter the key by hand:» ქვეშ, ქვემოთ — «Account: ლოგინი» და პარამეტრები «SHA-1, 6 digits, 30 seconds».
2. შეიყვანეთ კოდი. ველში 2. Code from the app შეიყვანეთ აპიდან ექვსი ციფრი და დააჭირეთ Next-ს. თუ ციფრები არ გამოდგა, გვერდი წერს The code did not match. Check the time on the phone.
3. შეინახეთ აღდგენის კოდები. სწორი კოდის შემდეგ ჩანს ათი ერთჯერადი კოდი (ბლოკი Save your recovery codes). ისინი საჭიროა, თუ ტელეფონი დაიკარგა. თითოეული კოდი ერთხელ მუშაობს. ღილაკები Download .txt (ფაილი bursu-pam-recovery-codes.txt) და Print. კოდები ტელეფონისგან განცალკევებით შეინახეთ.
4. დაადასტურეთ. მონიშნეთ I have saved the recovery codes და დააჭირეთ Next-ს. მონიშვნის გარეშე ღილაკი არ იმუშავებს.

საიდუმლო მიბმულია იმ სეანსზე, რომელმაც ის აჩვენა. თუ ამავე დროს ეს გვერდი კიდევ ერთხელ სხვა ფანჯარაში გაიხსნა, ახალი საიდუმლო ძველს ჩაანაცვლებს, ძველ გვერდზე კი გაფრთხილება გამოჩნდება: «Another session of this account started a new authenticator setup, so the code shown here before no longer works.» თუ ამ დროის განმავლობაში დაყენება სხვა ფანჯარაში უკვე დასრულდა, ეს შესვლა იხურება და ადამიანი შესვლის გვერდზე ბრუნდება. დადასტურების შემდეგ კარიბჭე ამ ადამიანის ყველა სხვა სეანსს ასრულებს.

Windows-ით შესვლა

ღილაკი Sign in with Windows გადადის გვერდზე /signin/windows. ბრაუზერმა თავად უნდა გაუგზავნოს კარიბჭეს Kerberos-ის ბილეთი. ბილეთის შემდეგ მაინც საჭიროა მეორე ფაქტორი: თუ ადამიანს TOTP არ აქვს, მას მაშინვე სთავაზობენ დაყენებას (პარამეტრი Require TOTP გათიშულიც რომ იყოს); თუ აქვს — კოდის შეყვანას, თუ ბრაუზერი «დამახსოვრებული» არ არის (იხ. პარამეტრი One code covers Windows sign-ins for (hours)). თუ შესვლა ვერ მოხერხდა, გვერდი შესვლის ფორმაზე აბრუნებს ერთ-ერთი ფრაზით; ყველა მათგანი ჩამოთვლილია თავში «გაუმართაობები». დაყენების შესახებ დეტალურად — განყოფილებაში Windows-ით შესვლა (Kerberos).

ხელახალი დადასტურება: გვერდი «Confirm it is you»

მისამართია /reauth. საშიში მოქმედებებისთვის კარიბჭე ითხოვს პაროლისა და კოდის ხელახლა შეყვანას, მაშინაც კი, თუ ადამიანი უკვე შესულია. ასეთი დადასტურება 10 წუთი მოქმედებს და მიმდინარე სეანსზეა მიბმული. დადასტურების შემდეგ კარიბჭე ადამიანს იმ გვერდზე აბრუნებს, საიდანაც გამოგზავნეს.

შეცდომა პაროლისა და კოდისთვის ერთია: The password or the code did not match. არასწორი პაროლი ან არასწორი კოდი ისევე ითვლება, როგორც შესვლისას, და ანგარიშის დაბლოკვამდე მიდის. როცა პაროლი და კოდი სწორია, წარუმატებლობების მთვლელი ნულდება.

დადასტურება საჭიროა: როლების შეცვლისთვის, სხვა ადამიანისთვის პაროლის დაყენებისა და მისი მეორე ფაქტორის გადაყენებისთვის; დირექტორიისა და მისი ჯგუფების შესაბამისობის დამატების, შეცვლისა და წაშლისთვის; დაშიფვრის გასაღებისა და გასაღების რეჟიმის შეცვლისთვის; პროფილში ახალი ავთენტიფიკატორის აპისა და აღდგენის ახალი კოდების შექმნისთვის; შესვლის პარამეტრების შესუსტებისთვის; და კონსოლის სხვა ნაწილებში რიგი მოქმედებებისთვის (წესები, ლიცენზია, SIEM და ა. შ. — ისინი თავიანთ განყოფილებებშია აღწერილი).

გასვლა: გვერდი «Sign out»

პუნქტი Sign out მომხმარებლის მენიუში სეანსს მაშინვე, შეკითხვის გარეშე ასრულებს. გვერდი /signout შეკითხვით «End your console session?» და ღილაკით Sign out იხსნება მხოლოდ მაშინ, თუ ამ მისამართზე პირდაპირ გადახვალთ (მაგალითად, სანიშნით). გასვლის შემდეგ სეანსი კარიბჭეზეა დახურული და არა მხოლოდ ბრაუზერში. გასვლა ასევე «ივიწყებს» ამ ბრაუზერს Windows-ით შესვლისთვის (დამახსოვრებული მოწყობილობა).

სეანსის სიცოცხლის ვადები

სეანსის დასრულებას შეტყობინება არ ახლავს: ადამიანი უბრალოდ შესვლის გვერდზე გადადის, შესვლის შემდეგ კი — იმ გვერდზე, რომელზეც იყო. სეანსის იდენტიფიკატორი ინახება cookie-ში __Host-bpam-session (მხოლოდ HTTPS-ისთვის, სკრიპტებისთვის მიუწვდომელი). შესვლის ყოველ ნაბიჯზე კარიბჭე cookie-ს ახალ მნიშვნელობას გასცემს.

ანგარიშის დაბლოკვა

ზედიზედ ხუთი არასწორი პაროლი ანგარიშს 15 წუთით ბლოკავს. ორივე რიცხვი პარამეტრია (Failed attempts before a lockout და Lockout length, min), ისინი ყოველი შესვლისას იკითხება. თავისებურებები:

• ითვლება არა მხოლოდ არასწორი პაროლები, არამედ მეორე ფაქტორის არასწორი კოდები და წარუმატებელი ხელახალი დადასტურებებიც.
• სწორი პაროლი თავისთავად მთვლელს არ ანულებს; მთვლელი ნულდება, როცა შესვლა სრულად დასრულდა ან როცა ხელახალი დადასტურება პაროლითა და კოდით წარმატებით გაიარა.
• თუ ბოლო წარუმატებლობიდან დაბლოკვის ხანგრძლივობაზე მეტი დრო გავიდა, დათვლა თავიდან იწყება.
• დაბლოკილი ადამიანი ხედავს Account temporarily locked until {0}. ადმინისტრატორს შეუძლია დაბლოკვა ვადამდე მოხსნას ღილაკით Unlock მომხმარებლის ბარათში.
• დირექტორიის მომხმარებლის დაბლოკვა ისევე მოქმედებს. გარდა ამისა, მოქმედებს თავად დირექტორიის დაბლოკვაც: ის გამოიყურება როგორც «Incorrect login or password».

ფანჯრის მოწყობა

კონსოლის ყოველი გვერდი შედგება ზედა პანელის, გვერდითი მენიუსა და სამუშაო არისგან.

ზედა პანელი

• მარცხნივ: ღილაკი Menu (ვიწრო ეკრანზე გვერდით მენიუს ხსნის) და სახელწოდება BURSU PAM; ის საწყის გვერდზე გადადის.
• Alerts — ზარი (იხ. ზარი).
• Language — ენების ჩამოსაშლელი სია. არჩევანი მაშინვე ინახება.
• Switch theme — ღილაკი მთვარით: ღია და მუქ თემას შორის გადართავს.
• მომხმარებლის მენიუ (User menu): ადამიანის სახელი. მასში სამი პუნქტია: My profile, Language and theme და Sign out.

გვერდითი მენიუ

მენიუ როლების მიხედვით არის შედგენილი და მხოლოდ იმას აჩვენებს, რისი გახსნაც ადამიანს შეუძლია. ღილაკი Collapse menu ქვემოთ მენიუს ჩაკეცავს. დამმტკიცებელს პუნქტის Approvals გვერდით უწერია იმ მოთხოვნების რიცხვი, რომლებიც მის გადაწყვეტილებას ელოდება. პუნქტი My profile გვერდით მენიუში მხოლოდ მაშინ ჩანს, თუ საერთო პუნქტების (My access და Help) გარდა ადამიანს არაფერი აქვს ხელმისაწვდომი, ანუ მას მხოლოდ ერთი როლი User აქვს; ყველა დანარჩენისთვის «My profile» ზემოთ, მომხმარებლის მენიუშია ხელმისაწვდომი.

მენიუ და პარამეტრების განყოფილებები: ინგლისური და ქართული

კონსოლი რვა ენაზეა თარგმნილი. ეკრანის ანაბეჭდებზე და ამ სახელმძღვანელოში ნაჩვენებია ინგლისური ინტერფეისი. ქვემოთ — გვერდითი მენიუს ყველა პუნქტი და განყოფილების Settings ყველა ფილა ინგლისური და ქართული წარწერებით თარგმანის ფაილებიდან (nav.*, sethub.*, role.*) და იმის მითითებით, ვინ ხედავს მათ.

გვერდითი მენიუ

ჯგუფის «Audit» პუნქტები და გვერდები «Approvals», «Command control», «Device profiles» და «Emergency access» აღწერილია სახელმძღვანელოს იმ ნაწილებში, რომლებიც აუდიტს, მოთხოვნებსა და რესურსებს ეხება. პუნქტი My access — მომხმარებლებისთვის განკუთვნილ ნაწილში.

განყოფილების «Settings» ფილები

როლების სახელწოდებები

ზარი «Alerts»

ზარი ზედა პანელის ხატულაა. მასზე მოცემული რიცხვი მიმდინარე პრობლემების რაოდენობაა. ის აქვთ ადმინისტრატორს, აუდიტორსა და დამმტკიცებელს, ასევე ნებისმიერ ადამიანს, რომელსაც მოთხოვნების შესახებ საკუთარი გაფრთხილებები აქვს. დაჭერა სიას ხსნის; თუ პრობლემები არ არის, წერია No current problems. ბმულიანი პუნქტი გადადის გვერდზე, სადაც პრობლემის გარჩევა შეიძლება; ადამიანს, რომლისთვისაც ეს გვერდი მიუწვდომელია, პუნქტი ბმულის გარეშე უჩანს.

თავად პრობლემების ჩამონათვალი (აქ — საერთო სურათი, დეტალები იმ განყოფილებებშია, რომლებზეც პუნქტები გადადის):

• ადამიანის საკუთარი ჩანაწერები: Requests waiting for your decision: {0}, Your requests that were decided: {0}, Commands waiting for your confirmation: {0}, ასევე გადაუდებელი წვდომის შესახებ (Emergency access used and not yet reviewed: {0} და Emergency access reviews overdue: {0}).
• საერთო პრობლემები ადმინისტრატორისა და აუდიტორისთვის: დაშიფვრის გასაღები დახურულია ან მოძველებულია, ბოლო ერთი საათის დაბლოკილი მომხმარებლები, ლოკალური ჟურნალის რიგი, სერვერის ჰოსტის გასაღების შეცვლა, დირექტორიები თვალყურის დევნების ან დადასტურებული ძირეული სერტიფიკატის გარეშე, სეანსების ჩაწერის შეფერხებები, დისკზე ადგილის ნაკლებობა, საათების აცდენა, SIEM ექსპორტის შეფერხება, ლიცენზიის პრობლემები, ჟურნალის ჯაჭვის დარღვევა და სხვა (მდგომარეობების სრული სია — განყოფილებაში Status).

ზოლები შიგთავსის ზემოთ

• ლიცენზიის გაფრთხილება. წითელი ან ყვითელი ზოლი, რომელსაც ყველა შესული ხედავს, სანამ ლიცენზიას ვადა გასულია, საშეღავათო ვადაშია, სხვა სერვერზეა მიბმული ან დაყენებული არ არის. ადმინისტრატორს ზოლში აქვს ბმული Open the licence page. ტექსტები და მოქმედებები — განყოფილებაში «ლიცენზია».
• გადაუდებელი წვდომის ზოლი. სანამ ადამიანს მისი საკუთარი გადაუდებელი წვდომა მოქმედებს, ყოველ გვერდზე წერია: «Emergency access is active until {0}. This use is recorded and will be reviewed.»
• მოქმედების შედეგი. შენახვის, წაშლის ან სხვა მოქმედების შემდეგ გვერდის ზემოთ მცირე ხნით ჩანს მწვანე (წარმატება) ან ყვითელი (გაფრთხილება) ზოლი შეტყობინებით: მაგალითად, Saved., Deleted., Created.
• წყლის ნიშანი. თუ პარამეტრი Watermark ჩართულია, კონსოლის მთელ ფანჯარაზე დიაგონალურად მეორდება შესული ადამიანის «ლოგინი (სახელი)».

ინტერფეისის ენა

კონსოლის ენა თითოეული ადამიანისთვის ცალკე აირჩევა. კარიბჭე ენას ასეთი თანმიმდევრობით ირჩევს — აიღება პირველი შესაფერისი:

1. ადამიანის პროფილში შენახული ენა (კონსოლში პირველი არჩევის შემდეგ);
2. cookie ბრაუზერის ენით (არჩევანი შესვლის გვერდზე ან ზედა პანელში);
3. ბრაუზერის სათაური Accept-Language;
4. ნაგულისხმევი ენა, რომელიც კარიბჭის პირველადი დაყენებისას აირჩიეს;
5. ინგლისური.

ხელმისაწვდომია რვა ენა: English (en), Deutsch (de), Español (es), Português — Portugal (pt), Português — Brasil (pt-br), Русский (ru), Українська (uk), ქართული (ka). არჩევანი ზედა პანელში ან გვერდზე Language and theme იწერება პროფილში და cookie-ში (ერთი წლით) და აუდიტის ჟურნალში ხვდება როგორც «Language changed».

გვერდი «Language and theme»

მისამართია /preferences. იხსნება მომხმარებლის მენიუდან და ხელმისაწვდომია ყველა შესულისთვის. ორი ფორმა:

გვერდი «My profile»

მისამართია /profile. მისი გახსნა ნებისმიერ შესულს შეუძლია. მხოლოდ User როლის მქონე ადამიანისთვის ეს მთელი კონსოლია, «My access»-ისა და დახმარების გარდა. რა არის გვერდზე:

ახალი ავთენტიფიკატორის აპი: გვერდი «New authenticator app»

მისამართია /profile/totp (ღილაკი Set up again). საჭიროა ხელახალი დადასტურება (10 წუთი). ნაბიჯები: დააჭირეთ Start-ს, დაასკანერეთ ახალი QR-კოდი, შეიყვანეთ კოდი ახალი აპიდან და დააჭირეთ Confirm-ს. დადასტურებამდე ძველი აპი აგრძელებს მუშაობას. დადასტურების შემდეგ კარიბჭე გასცემს აღდგენის ახალ ათ კოდს («New recovery codes replace the old ones»), ასრულებს ადამიანის ყველა სხვა სეანსს და ივიწყებს მის დამახსოვრებულ მოწყობილობებს. ღილაკი Done პროფილში აბრუნებს.

აღდგენის ახალი კოდები: გვერდი «New recovery codes»

მისამართია /profile/codes (ღილაკი Create new ones). საჭიროა ხელახალი დადასტურება. დააჭირეთ Create new codes-ს: ძველი კოდები მაშინვე წყვეტს მუშაობას, ახალი ათი კოდი ერთხელ ჩანს. შეინახეთ ისინი ღილაკით Download .txt ან ამობეჭდეთ (Print).

სიების საერთო ელემენტები

მომხმარებლების, ჯგუფებისა და მრავალი სხვა ობიექტის სიები ერთნაირად არის მოწყობილი:

• Quick filters — «ჩიპები» ცხრილის ზემოთ. თითოეულს მარჯვნივ ჩანაწერების რიცხვი აქვს. არჩეული ჩიპი გამოკვეთილია; All ფილტრს მოხსნის.
• ძიების სტრიქონი (ველი Search მინიშნებით, მაგალითად «Login, name, group»). კლავიში / კურსორს სტრიქონში გადაიყვანს. ძიება 200 სიმბოლომდე იჭრება; შაბლონის სიმბოლოებს განსაკუთრებული მნიშვნელობა არ აქვს.
• შექმნის ღილაკი (მაგალითად, Create user), მენიუ Actions ჯგუფური მოქმედებებით (ჩნდება სტრიქონების მოსანიშნი ველებით მონიშვნის შემდეგ), CSV (მთელი სიის ექსპორტი ფილტრისა და ძიების გათვალისწინებით; ექსპორტი აუდიტის ჟურნალში იწერება როგორც «audit.export») და Refresh.
• სვეტის სათაურზე დაწკაპუნება მის მიხედვით ალაგებს; განმეორებითი დაწკაპუნება მიმართულებას ცვლის.
• ქვემოთ: «Total: N», არჩევანი Per page (15, 30, 50 ან 100; ნაგულისხმევად 15) ღილაკით Apply და გვერდების ნომრები.
• ჯგუფური მოქმედება მონიშნულ სტრიქონებზე დადასტურებას ითხოვს: «Apply this action to the selected rows?» თუ არაფერია მონიშნული — «Nothing was selected.» თუ ფილტრმა ვერაფერი იპოვა — «Nothing matches this filter.»

დადასტურებები და შეუნახავი ცვლილებები

საშიში მოქმედებები (გათიშვა, წაშლა, გადაყენება) დადასტურებას ითხოვს ფანჯარაში ღილაკებით Confirm და Cancel. თუ JavaScript გათიშულია, იგივე დადასტურება თავად გვერდზე, ბლოკში «Confirm the action» ჩანს. ველებიანი ფორმები გაფრთხილებთ, თუ გვერდს შეუნახავი ცვლილებებით დახურავთ. ღილაკი Reset ველებს იმ მნიშვნელობებს უბრუნებს, რომლებითაც გვერდი გაიხსნა.

დრო და სასაათო სარტყელი

კარიბჭე დროს UTC-ში ინახავს, ხოლო აჩვენებს იმ სასაათო სარტყელში, რომელიც gateway.json-ში პარამეტრით displayTimeZone არის მითითებული (მაგალითად, Asia/Tbilisi). თუ პარამეტრი მითითებული არ არის, აიღება კარიბჭის ოპერაციული სისტემის სასაათო სარტყელი. თარიღი და დრო არჩეული ენის ფორმატით გამოიტანება. ეს სარტყელი ყველა მომხმარებლისთვის ერთნაირია; პროფილში ის არ იცვლება. იხ. განყოფილება gateway.json.

მომხმარებლები

განყოფილება Users (მისამართი /users) იმ ადამიანების სიაა, რომლებიც კონსოლში შედიან და კარიბჭის გავლით სერვერებს უკავშირდებიან. განყოფილება მხოლოდ ადმინისტრატორისთვისაა ხელმისაწვდომი (Administrator). მომხმარებლები ორი სახისაა:

• ლოკალური. მათ ადმინისტრატორი ქმნის. ლოგინი და პაროლი კარიბჭის ბაზაში ინახება (პაროლი — მხოლოდ შეუქცევადი ჰეშის სახით). პირველ ადმინისტრატორს პირველადი დაყენების ოსტატი ქმნის (იხ. განყოფილება პირველადი დაყენების ოსტატი).
• დირექტორიის მომხმარებლები (Active Directory ან LDAP). ისინი თავისით ჩნდებიან პირველი წარმატებული შესვლისას. კარიბჭეზე მათ პაროლი არ აქვთ; სახელი, როლები და ჯგუფებში წევრობა დირექტორიიდან მოდის (იხ. დირექტორიები).

მომხმარებლების სია

მისამართია /users. ცხრილის ზემოთ — სწრაფი ფილტრები (Quick filters), თითოეული ადამიანების რიცხვს აჩვენებს:

ძიება (Login, name, group) ეძებს ლოგინის, სახელისა და ჯგუფის სახელწოდების მიხედვით. ცხრილის სვეტები:

დალაგება შესაძლებელია სვეტებით Login, Name, Groups, State და Last sign-in. სტრიქონში მარჯვნივ — ღილაკი Edit (დირექტორიის მომხმარებლებს ის არ აქვთ) და მენიუ More actions: Open the card, Access (ბარათის ჩანართი «Access»), Log (ჩანართი «Log»). ღილაკი CSV სიის ექსპორტს ფილტრისა და ძიების გათვალისწინებით აკეთებს; ექსპორტი აუდიტის ჟურნალში ხვდება.

ჯგუფური მოქმედებები. მონიშნეთ სტრიქონები მოსანიშნი ველებით და გახსენით მენიუ Actions: Enable და Disable. Disable-ისთვის კარიბჭე დადასტურებას ითხოვს. სტრიქონები, რომლებსაც მოქმედება არაფერს უცვლის, ჟურნალში ჩაწერის გარეშე გამოიტოვება. თუ ჩართეთ დირექტორიის მომხმარებელი, რომელსაც დირექტორია კვლავ თიშავს, კარიბჭე გაგაფრთხილებთ: «Done for the selected rows. Users the directory disables stay disabled.»

მომხმარებლის შექმნა

ღილაკი Create user ხსნის გვერდს /users/new («Create user»). გვერდის მინიშნება: «A user created by an administrator changes the password and sets up TOTP at the first sign-in.»

(ვარსკვლავი სავალდებულო ველებს აღნიშნავს.)

Create-ზე დაჭერის შემდეგ გვერდი აჩვენებს «User {0} is created.» თუ პაროლი კარიბჭემ შექმნა, ქვემოთ ჩნდება ბლოკი Temporary password: «Give it to the user separately from the login. It is shown only now; they change it at the first sign-in.» პაროლი ერთხელ ჩანს; ის მაშინვე უნდა ჩაიწეროთ. ღილაკები: Open the card და Create user (კიდევ ერთის შექმნა). თუ პაროლი თავად შეიყვანეთ, პაროლიანი ბლოკი არ ჩანს.

რა იწერება აუდიტის ჟურნალში: მომხმარებლის შექმნა (User created) როლებით, ჯგუფებითა და ნიშნით «პაროლი გენერირებულია». თუ ჯგუფი, რომელშიც ადამიანი დაამატეთ, მოთხოვნების შაბლონში დამმტკიცებელთა ჯგუფად არის დასახელებული, ახალი დამმტკიცებლის შესახებ მოვლენაც იწერება.

მომხმარებლის შეცვლა

ღილაკი Edit (სიაში ან ბარათზე) ხსნის /users/{id}/edit-ს («Edit user {0}»). ველები იგივეა, რაც შექმნისას, გარდა ლოგინისა (ის მხოლოდ წასაკითხადაა) და პაროლების ბლოკისა. განსხვავებები:

• Roles. მოსანიშნი ველები ხელმისაწვდომია მხოლოდ ხელახალი დადასტურებიდან 10 წუთის განმავლობაში. სანამ დადასტურება არ არის, ველების ქვეშ წერია «Changing roles needs you to confirm who you are.» ბმულით Confirm who I am. თუ როლები დადასტურების გარეშე შეიცვალა, ფორმა უარს იტყვის: «Confirm who you are before changing roles.»
• Temporary password. ცარიელი — პაროლი ძველი რჩება («Leave empty to keep the current password.»). თუ პაროლს შეიყვანთ, საჭიროა ხელახალი დადასტურება: «Confirm who you are before setting a password.» ახალი პაროლი ადამიანმა შემდეგი შესვლისას უნდა შეცვალოს; მისი ყველა სეანსი იხურება, ხოლო შესვლის დაბლოკვა, თუ იყო, იხსნება (თუ პაროლს საკუთარ თავს უცვლით, მხოლოდ მიმდინარე სეანსი რჩება).
• Active. გადამრთველი მომხმარებელს თიშავს ან რთავს.
• ფორმა ჩანაწერის ვერსიის ნომერს ატარებს. თუ სხვა ადმინისტრატორმა იმავე ადამიანის შეცვლა მოასწრო, შენახვა უარს იტყვის: «The record was changed by another administrator — open it again.»

Save-ის შემდეგ კარიბჭე ბარათზე აბრუნებს შეტყობინებით Saved. ჟურნალში ყოველ ცვლილებაზე ერთი მოვლენა იწერება: ადამიანის მონაცემები, ჯგუფების დამატება და წაშლა, როლების შეცვლა (ძველი და ახალი მნიშვნელობით), ჩართვა ან გათიშვა, პაროლის გადაყენება.

დირექტორიის მომხმარებლების შეცვლა აქ არ შეიძლება: მათ ღილაკი Edit არ აქვთ, ხოლო მისამართზე გადასვლა ბარათზე მიგიყვანთ განმარტებით «This is set by the directory for domain users and cannot be changed here.»

მომხმარებლის ბარათი

მისამართია /users/{id}. სათაურში: სახელი, ლოგინი, დირექტორიის ჭდე (დირექტორიის მომხმარებლისთვის), ღილაკი Edit (დირექტორიის მომხმარებლების გარდა) და ღილაკი Disable / Enable. ჩანართები: Main, Groups, Access, Tokens, Log.

ჩანართი Main ორი ბლოკისგან შედგება.

ბლოკი Details: Login, Name, E-mail, Roles, Groups (ჭდე-ბმულები ჯგუფებზე), State (დაბლოკილისთვის — «until {0}»; დირექტორიის მომხმარებლისთვის — განმარტება «disabled in the directory», «expired in the directory», «in no mapped group» ან «no longer in the directory»), Two-factor sign-in (TOTP და «recovery codes left: N of 10» ან Not set up), Last sign-in, Created, Change password at the next sign-in. დირექტორიის მომხმარებელს ბოლოს ნაცვლად აქვს ბლოკი Source განმარტებით «Roles, directory groups, name and password of a domain user come from the directory.» და ბმულით Group mappings დირექტორიის ბარათზე.

ბლოკი Quick actions:

ჩანართი Groups — «The user's groups»: ცხრილი (Name, Description, Rules — ჯგუფის წესების რიცხვი). ზემოთ მარჯვნივ — ჯგუფის არჩევა და ღილაკი Add to group. ღილაკი Remove კითხულობს: «Remove {0} from the group {1}? The group's rules stop applying to them.» ჯგუფს, რომელშიც ადამიანი დირექტორიის წყალობით არის, აქვს ჭდე from the directory; თუ წევრობა მხოლოდ დირექტორიიდანაა, ღილაკი Remove არ არის — მას დირექტორიის ჯგუფების შესაბამისობა მართავს. თუ ადამიანი ჯგუფებში არ არის: «The user is in no group.»

ჩანართი Access — «Access to servers»: «From every rule in effect and every future one, directly and through groups.» სვეტები: Server, Address, Accounts, How (პირდაპირ ან ჯგუფის გავლით), Rule (ბმული), Valid until. თუ წესები არ არის: «No rule gives this user access.» ეს ჩანართი მხოლოდ წასაკითხადაა. შეგახსენებთ: სერვერებზე შესვლა მხოლოდ User როლის მქონე ადამიანს შეუძლია.

ჩანართი Tokens — «BURSUcm tokens» (BURSUcm აპის შესვლები კარიბჭის გავლით): სვეტები Issued, Expires, State; ღილაკი Revoke ტოკენს დაუყოვნებლივ აუქმებს («Token revoked.»). ქვემოთ — Remembered devices (Windows-ით შესვლისთვის დამახსოვრებული მოწყობილობები) და ღილაკი Forget devices (საჭიროა ხელახალი დადასტურება და მოქმედების დადასტურება: «Forget every remembered device of this person? Their next Windows sign-in asks the code.»).

ჩანართი Log — აუდიტის ჟურნალის ბოლო მოვლენები ამ ადამიანზე და ბმული მთელ ჟურნალზე.

დირექტორიის მომხმარებლები

• ანგარიში ჩნდება იმ ადამიანის პირველი წარმატებული შესვლისას, რომელიც ერთ შესაბამის ჯგუფში მაინც არის. ჟურნალში იწერება «Directory user created».
• ასეთი ადამიანის როლებსა და კარიბჭის ჯგუფებს ჯგუფების შესაბამისობა განსაზღვრავს (იხ. ჯგუფების შესაბამისობა). კონსოლში ხელით შეიძლება მხოლოდ მისი კარიბჭის ჯგუფში დამატება (ეს ცალკე, «ხელით» წევრობაა, რომელსაც დირექტორია არ ეხება), კონსოლში გათიშვა, MFA-ის გადაყენება და სეანსების დასრულება.
• მდგომარეობა დირექტორიაში: disabled in the directory, expired in the directory, in no mapped group, no longer in the directory. ყველა ამ შემთხვევაში ადამიანი ვერ შედის. დირექტორიაში გათიშვა მის სეანსებს მაშინვე წყვეტს; დირექტორიაში დაბლოკვა ახალ შესვლებს არ უშვებს, მაგრამ უკვე მიმდინარე სეანსებს არ წყვეტს.
• თუ დირექტორიის ჯგუფის შესაბამისობა მხოლოდ კარიბჭის ჯგუფს ასახელებს (როლის გარეშე), ადამიანს როლები არ გაუჩნდება, სერვერებზე კი მხოლოდ User როლი შედის (იხ. როლები). რომ დირექტორიიდან მოსულ ადამიანს სერვერებთან დაკავშირება შეეძლოს, მისი შესაბამისობებიდან ერთი მაინც უნდა იძლეოდეს როლს User.
• დირექტორიის მომხმარებლის პაროლი დირექტორიაში იცვლება.

ჯგუფები

ჯგუფი ადამიანებს აერთიანებს, რომ ერთი წვდომის წესი ყველაზე ერთბაშად მოქმედებდეს — ამჟამინდელ წევრებზეც და მათზეც, ვინც მოგვიანებით შეუერთდება. განყოფილება Groups (მისამართი /groups) მხოლოდ ადმინისტრატორს უჩანს. კარიბჭის ჯგუფი დირექტორიის ჯგუფთან დაკავშირებული არ არის, სანამ მათ შესაბამისობაში არ მოიყვანთ (იხ. ჯგუფების შესაბამისობა).

ჯგუფების სია

მისამართია /groups. თუ ჯგუფები ჯერ არ არის, ნაჩვენებია ეკრანი «No groups yet» განმარტებით «A group gathers users so one access rule covers all of them, now and when people join later.» და ღილაკით Create group.

ჯგუფის შექმნა და შეცვლა

ღილაკი Create group ხსნის /groups/new-ს, ღილაკი Edit — /groups/{id}/edit-ს («Edit group {0}»). ფორმა:

ჯგუფის ბარათი

მისამართია /groups/{id}. ღილაკები სათაურში: Edit და Delete. ჩანართები:

• Main: ბლოკი Details (სახელწოდება, აღწერა, წევრებისა და წესების რიცხვი, შექმნის თარიღი) და ჟურნალის ბოლო მოვლენები ჯგუფზე.
• Members: ადამიანების არჩევა ველში Add members («New members get the group's access at once.») და ღილაკი Add members. წევრების ცხრილში: Login, Name, State და ღილაკი Remove (დადასტურებით «Remove {0} from the group {1}? The group's rules stop applying to them.»). ჭდე from the directory აქვთ დირექტორიიდან მოსულ წევრებს; თუ წევრობა მხოლოდ დირექტორიიდანაა, ღილაკი Remove არ არის. სანამ წევრები არ არის: «The group has no members.»
• Rules: წესები, რომლებშიც ჯგუფია დასახელებული (Name, Valid until, State — Enabled ან Disabled). თუ არცერთი წესი ჯგუფს არ ასახელებს: «No rule names this group.» წესები იქმნება განყოფილებაში «Access rules» (იხ. წვდომის წესები).

ჯგუფის წაშლა

ბარათზე ღილაკი Delete კითხულობს: «Delete the group {0}? Its members ({1}) stay, but lose the access its rules ({2}) give.» წაშლა არ შეიძლება, თუ:

• ჯგუფი დირექტორიის შესაბამისობაშია გამოყენებული: The group is used by a directory mapping. Remove the mapping first.;
• ჯგუფს ბრძანებების კონტროლის პოლიტიკები მიმართავს: Command policies still apply to this: {0}. Edit the policies first. (ჯერ შეცვალეთ პოლიტიკები; იხ. განყოფილება ბრძანებების კონტროლი).

წაშლისას ადამიანები რჩებიან, მაგრამ კარგავენ წვდომას, რომელსაც მათ ამ ჯგუფის წესები აძლევდა. ჟურნალში იწერება «Group deleted».

აუდიტის ჟურნალი აფიქსირებს: ჯგუფის შექმნას, შეცვლასა და წაშლას, წევრის დამატებასა და წაშლას («Member added», «Member removed»). თუ ჯგუფის წევრი ამის წყალობით დამმტკიცებელი ხდება, ახალი დამმტკიცებლის შესახებ მოვლენაც იწერება (ის ზარშიც პუნქტს ქმნის).

როლები

როლი განსაზღვრავს, რას ხედავს ადამიანი კონსოლში და რისი შეცვლა შეუძლია მასში. ადამიანს შეიძლება რამდენიმე როლი ჰქონდეს. როლები მიეთითება მომხმარებლის ფორმაში (Users), დირექტორიის მომხმარებლებისთვის კი — ჯგუფების შესაბამისობაში (Directories). როლების სახელწოდებები ინტერფეისში: Administrator, Auditor, Approver, User.

როლები და კონსოლის განყოფილებები

ცხრილში: «დიახ» — ხედავს და შეუძლია შეცვლა; «წაკითხვა» — ხედავს, მაგრამ არ ცვლის; «—» — განყოფილება დამალულია.

Administrator და Approver შეუთავსებელია

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

• მომხმარებლის ფორმაში ორივე როლის არჩევისას კარიბჭე უარს იტყვის: Approver and Administrator exclude each other: nobody approves requests while managing the rules. Choose one of the two. იმავე მიზეზს ასახელებს საერთო შეცდომაც A person cannot be both an Administrator and an Approver.
• დირექტორიაში: თუ ადამიანის ჯგუფები ორივე როლს იძლევა, Approver როლი არ გაიცემა, ზარში კი ჩნდება გაფრთხილება Directory roles refused (Administrator wins over Approver): {0}. გამონაკლისი: თუ ადამიანს უკვე აქვს Approver (და არ აქვს Administrator), შესაბამისობები კი ახლა ორივეს იძლევა, რჩება ის როლი, რომელიც უკვე იყო, ანუ Approver, ხოლო უარყოფილია Administrator. დეტალურად — განყოფილებაში ჯგუფების შესაბამისობა.

ლოკალური ადმინისტრატორი («გადაუდებელი შესვლა»)

კარიბჭე ყოველთვის ინარჩუნებს ერთ აქტიურ ლოკალურ ადმინისტრატორს მაინც დაყენებული TOTP-ით. ეს წესი მოწმდება ყოველი ცვლილებისას, რომელსაც მისი დარღვევა შეეძლო. დირექტორიის მომხმარებლის ადმინისტრატორის როლი მხედველობაში არ მიიღება, რადგან დირექტორიას მისი ჩამორთმევა ნებისმიერ მომენტში შეუძლია (მაგალითად, დირექტორიის მიუწვდომლობისას თქვენ მაინც უნდა შეძლოთ შესვლა). ამიტომ:

• არ შეიძლება საკუთარი ადმინისტრატორის როლის მოხსნა («You cannot remove your own Administrator role.»);
• არ შეიძლება საკუთარი თავის გათიშვა («You cannot disable yourself.»);
• არ შეიძლება TOTP-ის მქონე ბოლო აქტიური ლოკალური ადმინისტრატორის გათიშვა, როლის ჩამორთმევა ან MFA-ის გადაყენება: At least one active administrator with two-factor sign-in must remain.

პირველადი დაყენების ოსტატის მიერ შექმნილი ადმინისტრატორი ლოკალურია. ნუ წაშლით და ნუ გათიშავთ მას, სანამ TOTP-ით სხვა ლოკალურ ადმინისტრატორს არ შექმნით. ნუ აურევთ ამ «გადაუდებელ» ანგარიშს ფუნქციასთან Emergency access (გადაუდებელი წვდომა სერვერზე წესის მიხედვით), რომელიც მოთხოვნების შესახებ ნაწილშია აღწერილი (იხ. გადაუდებელი წვდომა).

დირექტორიები (Active Directory და LDAP)

დირექტორია თანამშრომლებს საშუალებას აძლევს, კარიბჭეში საკუთარი დომენის პაროლით შევიდნენ, კარიბჭეზე ცალკე ანგარიშისა და პაროლის შექმნის გარეშე. კარიბჭე მხარს უჭერს Active Directory-სა და ჩვეულებრივ LDAP-სერვერებს (OpenLDAP, 389 Directory Server, FreeIPA). განყოფილება მდებარეობს Settings → Directories-ში (მისამართი /system/directories) და მხოლოდ ადმინისტრატორისთვისაა ხელმისაწვდომი. ერთდროულად რამდენიმე დირექტორიის დაკავშირება შეიძლება.

როგორ მუშაობს:

• კარიბჭე დირექტორიას სერვისული ანგარიშით (bind) მიმართავს: ეძებს ადამიანს ლოგინით და კითხულობს მის ჯგუფებს. ადამიანის პაროლი მოწმდება ცალკე «bind»-ით მისი სახელით და არსად ინახება.
• კავშირი მხოლოდ LDAPS-ით (დაშიფრული). სერვერისადმი ნდობა «ძირეულის მიმაგრებით» არის მოწყობილი: ადმინისტრატორი ადასტურებს ერთ ძირეულ სერტიფიკატს და კარიბჭე მხოლოდ იმ სერვერებს იღებს, რომელთა სერტიფიკატიც ამ ძირეულის ქვეშ არის გაცემული. სისტემური სერტიფიკაციის ცენტრები არ გამოიყენება.
• როლებსა და კარიბჭის ჯგუფებს ადამიანი ჯგუფების შესაბამისობით იღებს: «დირექტორიის ჯგუფი → როლი და/ან კარიბჭის ჯგუფი». ადამიანი, რომელიც არცერთ შესაბამის ჯგუფში არ არის, ვერ შედის.
• კარიბჭე დირექტორიას თვალყურს ადევნებს და ცვლილებებზე რეაგირებს: დირექტორიაში გათიშული ადამიანი წვდომას მაშინვე კარგავს, ჯგუფებში წევრობის ცვლილება წამებში გამოიყენება.

დირექტორიების სია

მისამართია /system/directories. მინიშნება: «Active Directory domains and LDAP servers whose users sign in to the gateway. Roles and gateway groups come from the directory groups mapped here.» თუ დირექტორიები არ არის, წერია: «No directory is connected. Only local users sign in.» ღილაკი Add directory დირექტორიას ქმნის.

დირექტორიის დამატება და შეცვლა

ღილაკი Add directory ხსნის /system/directories/new-ს («Add directory»); ბარათზე ღილაკი Edit — /system/directories/{id}/edit-ს («Change directory»). ორივე გვერდი ხელახალ დადასტურებას ითხოვს (10 წუთი).

(ვარსკვლავი სავალდებულო ველებს აღნიშნავს.)

Create-ის შემდეგ კარიბჭე ბარათს ხსნის შეტყობინებით «Directory added.» ჟურნალში იწერება «Directory added» (ტიპი, სერვერების რიცხვი, ნიშანი «ნაგულისხმევი»); შეცვლისას — «Directory changed» შეცვლილი ველების ჩამონათვლით, სერტიფიკატის გაუქმების ნიშნითა და პაროლის შეცვლის ნიშნით (თავად პაროლი ჟურნალში არ ხვდება).

დირექტორიის ბარათი

მისამართია /system/directories/{id}. სათაურში: Edit და Delete (იხ. წაშლა და გათიშვა). ბარათის ბლოკები:

• Connection: ტიპი, სერვერები, ორივე DN, სუფიქსები და NetBIOS (AD-სთვის), ნაგულისხმევობის ნიშანი, Bind DN, Turned on, State, Last change seen (როდის შეატყობინა დირექტორიამ ბოლოს ცვლილების შესახებ) და Gateway users from it (კარიბჭის რამდენი მომხმარებელი მოვიდა ამ დირექტორიიდან).
• Root certificate: დადასტურებული ძირეული (SHA-256 ანაბეჭდი ან «Not confirmed yet»), ღილაკი Check connection, სერვერის მიერ წარმოდგენილი ძირეული, ღილაკი Confirm this certificate და ძირეულის ფაილის ატვირთვა.
• Windows sign-in (Kerberos) — მხოლოდ AD-ს აქვს (იხ. Windows-ით შესვლა).
• Group mappings (იხ. ჯგუფების შესაბამისობა).

ბარათზე მოქმედებები, რომლებიც რაიმეს ცვლის (სერტიფიკატის დადასტურება და ატვირთვა, შესაბამისობები, წაშლა, გათიშვა), ხელახალ დადასტურებას ითხოვს (10 წუთი); მის გარეშე კარიბჭე დადასტურების გვერდზე გადაგამისამართებთ და უკან დაგაბრუნებთ. ღილაკი Check connection და ჯგუფების ძიება ხელახალ დადასტურებას არ ითხოვს. დირექტორიისადმი მიმართვის მოქმედებები შეზღუდულია: ერთი მისამართიდან წუთში 10 დაჭერა, ჯგუფების ძიება — სეანსზე წუთში 20.

კავშირის შემოწმება

ღილაკი Check connection არაფერს ცვლის. ის ცდილობს სერვისული ანგარიშით შესვლას, მომხმარებლების ძიების შესრულებას და იმის გარკვევას, შეუძლია თუ არა სერვერს ცვლილებების შეტყობინება, და ამავე დროს კითხულობს სერტიფიკატს, რომელსაც სერვერი წარადგენს. შედეგი ჟურნალის ჩანაწერშია «Directory connection checked». წარმატება ასე გამოიყურება: «Signed in as the service account; entries found: N.» და, ქვემოთ, «The directory reports changes.» (ან «This directory does not report changes; access is re-checked at the next sign-in or connection.»). თუ ვერ მოხერხდა, ნაჩვენებია ერთ-ერთი შეტყობინება (ყველა მათგანი ჩამოთვლილია თავშიც «გაუმართაობები»):

ძირეული სერტიფიკატის დადასტურება

სანამ ძირეული დადასტურებული არ არის, კარიბჭე დირექტორიას არ იყენებს: ის სერვერის სერტიფიკატს «სიტყვაზე» არასოდეს ენდობა. ძირეულის დადასტურება ორი გზით შეიძლება.

1. დააჭირეთ «Check connection»-ს. თუ სერვერმა სერტიფიკატების ჯაჭვი ძირეულთან ერთად გამოგზავნა, შედეგის ქვემოთ გამოჩნდება Presented root (SHA-256 ანაბეჭდი) და Answered by (რომელმა სერვერმა უპასუხა). შეადარეთ ანაბეჭდი დამოუკიდებელი არხით (სერტიფიკაციის ცენტრის მფლობელისგან) მიღებულ ეტალონს და დააჭირეთ Confirm this certificate-ს. კარიბჭე ჯაჭვს კიდევ ერთხელ წაიკითხავს და ძირეულს მხოლოდ მაშინ შეინახავს, თუ ის იგივეა, რაც თქვენ ნახეთ, და თუ ყოველი მითითებული სერვერის სერტიფიკატი მის ქვეშ არის აგებული და ამ სერვერს ასახელებს.
2. ატვირთეთ ძირეულის ფაილი. Active Directory-ს დომენის კონტროლერი ჩვეულებრივ მხოლოდ საკუთარ სერტიფიკატს აგზავნის, ძირეულის გარეშე («The directory did not send its root certificate. Upload it (.cer or .pem).»). გაიტანეთ დომენის სერტიფიკაციის ცენტრის ძირეული სერტიფიკატი (DER ან Base-64) და ატვირთეთ ის ველში Root certificate file ღილაკით Upload. მიიღება ფაილები .cer, .crt, .pem, .der 64 კბ-მდე ზომით და მხოლოდ სერტიფიკაციის ცენტრის თვითხელმოწერილი სერტიფიკატი.

შედეგი: «The certificate is confirmed.» და ჟურნალში ჩანაწერი «Directory certificate confirmed». შესაძლო უარები:

ჯგუფების შესაბამისობა

ბლოკი Group mappings დირექტორიის ბარათზე: «A person in a mapped group signs in with the role and joins the gateway group given here. A person in no mapped group cannot sign in.» დირექტორიის თითოეული ჯგუფისთვის აირჩევა როლი და/ან კარიბჭის ჯგუფი (საკმარისია ერთ-ერთი: «Choose a role or a gateway group.»). ბლოკი ხელმისაწვდომია მხოლოდ ძირეულის დადასტურების შემდეგ («Confirm the root certificate first: until then the gateway does not search this directory.»).

1. იპოვეთ ჯგუფი. ველში Find a directory group შეიყვანეთ სახელწოდების ნაწილი (128 სიმბოლომდე) და დააჭირეთ Search-ს. თუ ჯგუფები არ არის: «No group matches.» ჯგუფს, რომელიც უკვე შესაბამისობაშია, აქვს ნიშანი already mapped. ჯგუფების ძიება დამთხვევების შეზღუდულ რიცხვს აბრუნებს; დააზუსტეთ მოთხოვნა.
2. აირჩიეთ, რას იძლევა ის. სიაში Role — no role, User, Auditor, Approver ან Administrator; სიაში Gateway group — no group ან კარიბჭის ერთ-ერთი ჯგუფი.
3. დააჭირეთ «Map»-ს. შესაბამისობა შენახულია: «Mapping saved.» კარიბჭე დირექტორიის ადამიანებს მაშინვე თავიდან კითხულობს: «what the mapping gives reaches them within seconds». თუ დირექტორია ამ მომენტში არ იკითხება: «Mapping saved. The directory cannot be read now: what the mapping no longer gives is already taken away; what it gives arrives once the directory can be read again.»

არსებული შესაბამისობის შეცვლა შეიძლება პირდაპირ ცხრილში (სიები Role და Gateway group, ღილაკი Save) ან წაშლა (Delete, დადასტურება «Remove the mapping of {0}?»). შეცვლა და წაშლა დირექტორიის ყველა ადამიანზე ერთბაშად ვრცელდება: რისი მიცემაც შესაბამისობამ შეწყვიტა, მაშინვე ჩამოერთმევათ; რასაც ის იძლევა, მოვა, როცა დირექტორია წაიკითხება.

როგორ იკრიბება უფლებები:

• ადამიანი იღებს ყველაფრის გაერთიანებას, რასაც იმ ჯგუფების შესაბამისობები იძლევა, რომლებშიც ის არის (მათ შორის ჩადგმულ ჯგუფებში).
• დირექტორიის ერთი ჯგუფი მხოლოდ ერთხელ მოიყვანება შესაბამისობაში. მომხმარებლის ძირითადი ჯგუფი (მაგალითად, Domain Users AD-ში) შესაბამისობაში ვერ მოიყვანება: «A user's primary group (Domain Users) cannot be mapped: Active Directory does not list it as a membership.»
• დირექტორიიდან მიღებული წევრობა კარიბჭის ჯგუფში ბარათზე მონიშნულია როგორც from the directory და შესაბამისობასთან ერთად ავტომატურად იხსნება. ხელით წევრობას (ადმინისტრატორის მიერ კონსოლში დამატებულს) დირექტორია არ ეხება.
• ადმინისტრატორი და დამმტკიცებელი შეუთავსებელია (როლები). თუ შესაბამისობები ორივე როლს ერთად იძლევა, გაიცემა Administrator, ხოლო Approver უარყოფილია. თუ ადამიანს უკვე აქვს Approver (და არ აქვს Administrator), შესაბამისობები კი ახლა ორივე როლს იძლევა, რჩება Approver, ხოლო უარყოფილია Administrator. უარყოფილი როლი ზარში ჩანს: Directory roles refused (Administrator wins over Approver): {0}. გაითვალისწინეთ, რომ ბარათზე მინიშნება («A person whose groups give both Administrator and Approver gets Administrator only») მხოლოდ პირველ შემთხვევას აღწერს.
• კარიბჭის ჯგუფს, რომელსაც შესაბამისობა მიმართავს, ვერ წაშლით, სანამ შესაბამისობა არ მოიხსნება (The group is used by a directory mapping. Remove the mapping first.).

თვალყურის დევნება და გადამოწმება

• ყოველი ჩართული დირექტორიისთვის დადასტურებული ძირეულით კარიბჭე ინარჩუნებს გამოწერას მომხმარებლებისა და ჯგუფების შტოებში ცვლილებებზე (Active Directory-ს შეტყობინებები; LDAP-ისთვის — syncrepl ან persistent search). ცვლილება წამებში მოდის. მდგომარეობა watched ნიშნავს, რომ გამოწერა მუშაობს.
• გარდა ამისა, კარიბჭე დირექტორიის ყველა ადამიანს პერიოდულად თავიდან ამოწმებს (არანაკლებ 15 წუთში ერთხელ), ასევე ადამიანის ყოველი შესვლისას და სერვერთან დასაკავშირებლად მისი ბილეთის შემოწმებისას.
• დირექტორიაში ადამიანის გათიშვა ან წაშლა, მის მიერ ყველა შესაბამისი ჯგუფის დაკარგვა, დირექტორიაში პაროლის შეცვლა მისი სეანსების დასრულებასა და ტოკენების გაუქმებას იწვევს. დირექტორიაში დაბლოკვა ახალ შესვლებს არ უშვებს, მაგრამ უკვე მიმდინარე სეანსებს არ წყვეტს.
• თუ დირექტორია მიუწვდომელია, კარიბჭე «ყოველი შემთხვევისთვის» არ უშვებს: წვდომა, რომელიც ერთმევა, ერთმევა; წვდომა, რომელიც გაიცემა, დირექტორიის წაკითხვის შესაძლებლობას ელოდება. თუ დირექტორია შესვლისას მიუწვდომელია, ადამიანი ხედავს «The directory is not available. Try again later or contact the administrator.» ლოკალური მომხმარებლები, მათ შორის გადაუდებელი ადმინისტრატორი, ყოველთვის შედიან.

დირექტორიის წაშლა და გათიშვა

ბარათის სათაურში ღილაკი Delete კითხულობს: «Delete directory {0}?» ის მხოლოდ მაშინ ჩანს, როცა ამ დირექტორიიდან ჯერ არავინ შესულა. თუ დირექტორიიდან ადამიანები უკვე შედიოდნენ, მისი წაშლა არ შეიძლება: «Users signed in from this directory exist. Turn the directory off instead of deleting it.» ამის ნაცვლად ბარათზე არის ღილაკი Turn off შეკითხვით «Turn off directory {0}? Its users cannot sign in until it is turned on again.» (მის შემდეგ: «Users signed in from this directory exist, so it cannot be deleted. It is turned off; turn it on again in its settings.»). დირექტორიის ჩართვა შეიძლება შეცვლის ფორმაში (Turned on). ჟურნალში იწერება «Directory deleted» ან «Directory changed».

Windows-ით შესვლა (Kerberos)

Active Directory-სთვის შესვლის გვერდზე შეიძლება ღილაკის Sign in with Windows ჩართვა: დომენში შესული თანამშრომელი კონსოლში პაროლის შეყვანის გარეშე ხვდება (შემდეგ კარიბჭე მაინც ითხოვს მეორე ფაქტორს). ღილაკი შესვლის გვერდზე მხოლოდ მაშინ ჩნდება, თუ ერთი ჩართული AD დირექტორიისთვის მაინც ყველაფერი მზადაა (SPN, დომენის ანგარიში ან keytab ფაილი, შემოწმება გავლილია).

ბლოკი Windows sign-in (Kerberos) AD-ის ბარათზე აჩვენებს, ჩართულია თუ არა შესვლა, SPN-ს, გასაღების ვერსიის ნომერს (kvno) და დაშიფვრის ტიპებს, და გადადის გვერდზე /system/directories/{id}/kerberos («Windows sign-in (Kerberos)»).

კარიბჭე Linux-ზე: გასაღებების ფაილი (keytab)

Linux-ზე კარიბჭეს სჭირდება keytab ფაილი სერვისული სახელის HTTP/… გასაღებებით. ბლოკი Keytab აჩვენებს Principal-ს (SPN და realm), Key version (kvno)-ს, Encryption types-ს, Uploaded-ს (როდის და ვის მიერ) და, გასაღების შეცვლის შემდეგ, «Previous key (kvno N) kept until» (ძველი გასაღები კიდევ 10 საათი რჩება, რომ უკვე გაცემულმა ბილეთებმა მუშაობა გააგრძელონ). ღილაკები: Upload keytab (ფაილის .keytab არჩევის ველი) და Remove keytab (დადასტურება «Remove the keytab of {0}? Windows sign-in through this directory stops.»). ფაილი კარიბჭეზე დაშიფრულად ინახება; კონსოლში მისი შიგთავსი არ ჩანს.

როგორ მიიღოს ადმინისტრატორმა keytab. გასაღებები ისე უნდა იყოს მარილით (salt) დამუშავებული, როგორც მათ დომენის კონტროლერი ამუშავებს იმ ანგარიშისთვის, რომელზეც SPN არის მიბმული. მომხმარებლის ანგარიშისთვის მარილი უდრის REALM + sAMAccountName. სამი გზიდან ნებისმიერი (კარიბჭე იმავე მინიშნებას გვერდზე აჩვენებს):

1. MIT ktutil (Active Directory-ში არაფრის შეცვლა არ არის საჭირო):

   ktutil
   addent -password -p HTTP/<host>@<REALM> -k <kvno> -e aes256-cts-hmac-sha1-96 -s <REALM><account>
   addent -password -p HTTP/<host>@<REALM> -k <kvno> -e aes128-cts-hmac-sha1-96 -s <REALM><account>
   wkt gateway.keytab

   აქ <kvno> ანგარიშის msDS-KeyVersionNumber-ის მნიშვნელობაა, <account> — მისი sAMAccountName (დომენის გარეშე).
2. msktutil. უტილიტა სერვისული ანგარიშისთვის საჭირო მარილსა და გასაღების ვერსიას თავად ითვლის; მისი პარამეტრები უტილიტის დოკუმენტაციაში ნახეთ.
3. ktpass პარამეტრებით +setpass +setupn დომენის კონტროლერზე. გახსოვდეთ, რომ ktpass ანგარიშს ახალ პაროლს აყენებს და გასაღების ვერსიას ზრდის, ამიტომ ამ ანგარიშის სხვა keytab ფაილები აღარ გამოდგება.

ფაილის მოთხოვნები: ფორმატის ვერსია 0x0502 (მას წერენ ktpass და ktutil); ერთი ჩანაწერი მაინც; ყველა ჩანაწერი ამ დირექტორიის realm-ისა და ამ დირექტორიის SPN-ისთვის; ზომა 64 კბ-მდე; მხოლოდ AES გასაღებები (RC4, DES და 3DES მთელ ფაილს უარყოფს). თუ ფაილში მხოლოდ AES128 არის, ის გაფრთხილებით მიიღება (რეკომენდებულია AES256). ატვირთვის შემდეგ კარიბჭე გასაღებს მაშინვე საცდელი ბილეთით ამოწმებს. ჟურნალი: «Kerberos keytab changed» (გასაღების შიგთავსის გარეშე).

კარიბჭე Windows-ზე

Windows-ზე keytab არ არის საჭირო: კარიბჭის სერვისი დომენის ანგარიშით ეშვება (რეკომენდებულია gMSA), SPN კი მასზე რეგისტრირდება. გვერდი Keytab ბლოკის ნაცვლად აჩვენებს The service runs as-ს (რომელი ანგარიშით მუშაობს სერვისი) და Host joined to the domain-ს (ჩართულია თუ არა კომპიუტერი დომენში). მათთვის, ვინც შევა, კარიბჭის კომპიუტერზე უნდა იყოს უფლება «Access this computer from the network» (ამ კომპიუტერთან წვდომა ქსელიდან); თუ Tier-0 დონის ჯგუფური პოლიტიკა მას კრძალავს, ამ ადამიანებთან Windows-ით შესვლა არ მუშაობს.

ღილაკი «Check Kerberos»

ღილაკი Check Kerberos შემოწმებას უშვებს და აჩვენებს სტრიქონებს დონით (ok, info, warn, bad): ვარგისია თუ არა keytab და გარემო, ვის უჭირავს SPN, ემთხვევა თუ არა kvno, ხომ არ არის დაშვებული დაშიფვრის სუსტი ტიპები, ხომ არ არის ჩართული დელეგირება, ხომ არ არის სერვისული ანგარიში ჯგუფებში, მიიღება თუ არა საცდელი ბილეთი არხთან მიბმით, ხომ არ არის კონტროლერის პორტი 88 მიუწვდომელი, ხომ არ აცდენს საათები (3 წუთის აცდენისას — გაფრთხილება, 5 წუთისას — შესვლა წყვეტს მუშაობას). ყველა სტრიქონი ჩამოთვლილია თავში «გაუმართაობები». შემოწმება ჟურნალში წერს «Directory connection checked».

დამატებითი მინიშნებები გვერდზე:

• ბრაუზერები ბილეთს მხოლოდ იმ სახელებს უგზავნიან, რომლებიც მათ პოლიტიკაშია: ზონა «Local intranet» (ლოკალური ინტრანეტი) ან AuthServerAllowlist Edge-ისა და Chrome-ისთვის, network.negotiate-auth.trusted-uris Firefox-ისთვის. დააყენეთ ეს ჯგუფური პოლიტიკით.
• Windows-ით შესვლა მოითხოვს, რომ დაშიფრული TLS კავშირი კარიბჭეზე სრულდებოდეს (მხოლოდ TCP-ის გამჭოლი გადაცემა). თუ gateway.json-ში სანდო პროქსებია მითითებული, გვერდი ამის შესახებ გაფრთხილებთ.
• პარამეტრი Channel binding for console sign-ins (Sign-in and MFA) განსაზღვრავს, საჭიროა თუ არა არხთან მიბმა. ნაგულისხმევი მნიშვნელობა — სავალდებულოა.

Linux და ცვლადი LDAPNOINIT

Linux-ზე კარიბჭე უნდა გაეშვას თავისი systemd ერთეულით (bursu-pam-gateway.service): ის აყენებს LDAPNOINIT=1-ს, რომლის გარეშეც დირექტორიით შესვლა არ მუშაობს. მიზეზი: ამ ცვლადის გარეშე LDAP-ის ბიბლიოთეკა კითხულობს სისტემურ ფაილს /etc/ldap/ldap.conf, Ubuntu-ზე კი იქ სერტიფიკაციის ცენტრების სისტემური ნაკრებია მითითებული; მაშინ კარიბჭე ნებისმიერ საჯარო ცენტრს ენდობოდა და არა მხოლოდ თქვენ მიერ დადასტურებულ ძირეულს. ამიტომ ცვლადის გარეშე კარიბჭე დირექტორიებთან დაკავშირებაზე უარს ამბობს (უსაფრთხო უარი):

• დომენის შესვლები პასუხობს «The directory is not available…»;
• ზარი დირექტორიას აჩვენებს როგორც «თვალყურის დევნების გარეშე» (Directories not watched);
• Check connection წერს, რომ Linux-კარიბჭეზე LDAPNOINIT=1 მითითებული არ არის.

გამოსავალი: გაუშვით კარიბჭე systemd ერთეულით, რომელსაც პაკეტი აყენებს. ლოკალური ანგარიშები, მათ შორის გადაუდებელი ადმინისტრატორი, ისედაც შედიან. Windows-ზე დამატებით არაფერია საჭირო: ძირეული კარიბჭის საკუთარი მექანიზმით მოწმდება. ყოველ დირექტორიას დისკზე აქვს საკუთარი ნდობის საქაღალდე <dataDirectory>/directories/<id>/, რომელსაც კარიბჭე თავად გადაწერს; იქ ფაილებს ნუ ჩადებთ.

დირექტორიით შესვლის ცნობილი შეზღუდვები

• ჩადგმული ჯგუფები ჯგუფების შტოს გარეთ. ჩადგმული ჯგუფების წევრები ჯაჭვის გავლით მოიძებნება (AD LDAP_MATCHING_RULE_IN_CHAIN). მაგრამ თუ შუალედური ჯგუფი შტოს Groups base DN გარეთაა, მისი ცვლილება შეტყობინებით არ მოდის და გამოიყენება შემდეგი გადამოწმებისას (არაუგვიანეს 15 წუთისა) ან შემდეგი შესვლისას ან ბილეთის შემოწმებისას. ასეთი ჯგუფები ჯგუფების შტოში შეინახეთ ან დომენის ძირი მიუთითეთ.
• LDAP ppolicy-ის გადაფარვის (overlay) გარეშე. ატრიბუტის pwdChangedTime გარეშე დირექტორიაში პაროლის შეცვლა არ აღმოჩნდება: ადამიანის ძველი სეანსები არ იხურება, ხოლო ვადაგასული პაროლი არასწორს ჰგავს. ორივე შემთხვევაში კარიბჭე უარს ამბობს და არა უშვებს. OpenLDAP-სა და 389-DS-ზე ჩართეთ ppolicy.
• დირექტორიაში დაბლოკვა ახალ შესვლებსა და ახალ ბილეთებს არ უშვებს, მაგრამ უკვე მიმდინარე სეანსებს არ ასრულებს (Windows-იც ასევე იქცევა დაბლოკილი ანგარიშის სეანსებთან); გათიშვა ასრულებს.

განყოფილება «Settings»: კარიბჭის პარამეტრები

კარიბჭის ყველა პარამეტრი თავმოყრილია ერთ გვერდზე Settings (მისამართი /settings). ეს გვერდითი მენიუს ერთადერთი პუნქტია ყველაფრისთვის, რასაც ადმინისტრატორი კარიბჭეზე აყენებს. გვერდი მხოლოდ ადმინისტრატორს უჩანს: სხვა როლებს პუნქტი Settings არ აქვთ. მინიშნება გვერდზე: «Everything an administrator configures on the gateway, in one place. Each tile opens its page; changes are audited as before.»

გვერდი შედგება ფილებისგან, რომლებიც ოთხ ჯგუფად არის დაჯგუფებული. ყოველი ფილა მოკლე წარწერით პარამეტრის გვერდის ბმულია. თავად გვერდები კვლავ /system/… მისამართებზე მდებარეობს: ბრაუზერის სანიშნეები და ზარის ბმულები ისევე მუშაობს, როგორც ადრე.

პარამეტრების გვერდების საერთო წესები:

• პარამეტრის ყოველი ჩაწერა აუდიტის ჟურნალში ძველ და ახალ მნიშვნელობასთან ერთად ხვდება.
• პარამეტრები, რომლებიც დაცვას ამცირებს (მაგალითად, ორფაქტორიანი შესვლის გათიშვა), პიროვნების ხელახალ დადასტურებას ითხოვს (ხელახალი დადასტურება). დაცვის გაძლიერება დადასტურებას არ ითხოვს.
• თუ სხვა ადმინისტრატორმა იგივე გვერდი თქვენზე ადრე შეინახა, კარიბჭე არაფერს წერს და გატყობინებთ: «The record was changed by another administrator — open it again.» გახსენით გვერდი თავიდან და გაიმეორეთ ცვლილება.
• შეუნახავი ცვლილებებით გვერდიდან წასვლამდე ბრაუზერი ცვლილებების დაკარგვის შესახებ გაფრთხილებთ.

Sign-in and MFA: შესვლა და ორფაქტორიანი დაცვა

გვერდი Sign-in and MFA (მისამართი /system/auth, მხოლოდ ადმინისტრატორი) კონსოლში შესვლის წესებს ყველა ადამიანისთვის ადგენს: TOTP-კოდის სავალდებულობას, დაბლოკვას წარუმატებელი მცდელობების შემდეგ, პაროლის სიგრძეს, უმოქმედობის დროს, BURSUcm-ის ტოკენების ვადას, ტექსტს შესვლის გვერდზე, წყლის ნიშანს და Windows-ით შესვლის პარამეტრებს. მინიშნება გვერდის ზედა ნაწილში: «Every change goes into the audit log with the old and the new value.»

ყველა ველი ერთი ღილაკით Save ინახება და მაშინვე მოქმედებს (გარდა იმ შესვლებისა, რომლებიც უკვე შუალედურ ნაბიჯებზეა). ღილაკი Reset ფორმაში აბრუნებს მნიშვნელობებს, რომლებიც მისი გახსნისას იყო. შენახვის შემდეგ გვერდი აჩვენებს «Saved.».

რომელი ცვლილებები მოითხოვს ხელახალ დადასტურებას

ცვლილებას, რომელიც დაცვას ამცირებს, მხოლოდ მოპარული სეანსით ვერ გააკეთებთ. თუ დაცვის შემცირებას ცდილობთ ვინაობის ახალი დადასტურების გარეშე (10 წუთი), გვერდი არ ინახება და თითოეულ ასეთ ველთან ჩნდება შეტყობინება «Confirm who you are before this change: …. It lowers sign-in protection.» (TOTP-ის გამორთვისთვის: «Confirm who you are before turning two-factor sign-in off.») ბმულით Confirm who I am. გაიარეთ დადასტურება და დაბრუნდით გვერდზე; შეყვანილი მნიშვნელობები ხელახლა მოგიწევთ.

• დადასტურებას მოითხოვს: Require TOTP-ის გამორთვა, მცდელობების რაოდენობის გაზრდა, დაბლოკვის ხანგრძლივობის შემცირება, პაროლის მინიმალური სიგრძის შემცირება, უმოქმედობის დროის გაზრდა, ტოკენის ვადის გაზრდა, წყლის ნიშნის გამორთვა, Windows-ის კოდის «დამახსოვრების» დროის გაზრდა, გადასვლა When the browser sends it-ზე.
• არ მოითხოვს: ნებისმიერი გაძლიერება, ასევე ბანერის ტექსტის შეცვლა.

Encryption key: დაშიფვრის გასაღები

კარიბჭე სერვერების ანგარიშების პაროლებსა და გასაღებებს (თავი Accounts) დაშიფრული სახით ინახავს. დაშიფვრის გასაღებად კარიბჭის «მთავარი» გასაღები გამოიყენება. გვერდი Encryption key (მისამართი /system/key, მხოლოდ ადმინისტრატორი) აჩვენებს მის მდგომარეობას და საშუალებას იძლევა შეცვალოთ თავად გასაღები ან მისი დაცვის ხერხი. მინიშნება: «The key the gateway encrypts account secrets with. Changing the key or its mode needs a fresh confirmation and a typed word.»

გასაღების პირველი შექმნა და რეჟიმის არჩევა პირველადი დაყენებისას ხდება (პირველადი დაყენება); საიდუმლო ფრაზის შეყვანა ყოველი გაშვებისას აღწერილია თავში «ლუქის მოხსნა».

გასაღების დაცვის ორი რეჟიმი

რას აჩვენებს გვერდი

დამატებითი შეტყობინებები გვერდზე:

• წითელი ჩარჩო «The encryption key was changed, and this gateway still holds the previous one in memory. Restart the gateway (a sealed gateway will need its passphrase).» — მოქმედების ღილაკების ნაცვლად. სანამ სერვისს არ გადატვირთავენ, ახალი საიდუმლოებების ჩაწერა არ მუშაობს. გადატვირთეთ სერვისი და შეამოწმეთ აუდიტის ჟურნალი.
• გაფრთხილება «These key files were set aside in the key directory. One may be the old key from before a change: delete it once you are sure it is not another database's key.» ფაილების სიითა და განმარტებით «The console cannot remove them: an administrator of the server's operating system can archive or delete them.» გასაღების ძველი ფაილები შეცვლის შემდეგ გვერდზე გადაიდება და არ იშლება: ისინი სერვერზე ხელით უნდა წაშალოთ, მას შემდეგ რაც დარწმუნდებით, რომ ფაილი საჭირო არ არის.

გასაღების შეცვლა (Change the key)

გვერდი /system/key/rotate («Change the encryption key»). საჭიროა ხელახალი დადასტურება (10 წუთი) და აკრეფილი სიტყვა. ოპერაცია — წუთში არაუმეტეს 5-ჯერ.

ბლოკი «What happens» შედეგებს ჩამოთვლის:

• «The gateway makes a new key and re-encrypts all N secrets with it.»
• «The old recovery key stops working; the new one is shown once.»
• «Connections are not accepted during the change (seconds).»
• «The change goes into the audit log.»

1. გახსენით ფორმა. გვერდზე Encryption key დააჭირეთ Change the key. თუ კარიბჭე Sealed რეჟიმშია, ფორმაში არის ველი Current unseal passphrase.
2. შეიყვანეთ მონაცემები. Sealed რეჟიმისთვის — მიმდინარე საიდუმლო ფრაზა. შემდეგ ველში «Type … to continue» აკრიფეთ დადასტურების სიტყვა — ის ველის წარწერაშია ნაჩვენები. სიტყვა ინტერფეისის ენაზეა დამოკიდებული: ინგლისურში ეს არის CHANGE, ქართულში — შეცვლა. აკრიფეთ ის ზუსტად, ისე როგორც ნაჩვენებია (ინგლისური სიტყვა — დიდი ასოებით), და იმ ენაზე, რომელიც გვერდზეა ნაჩვენები; ჰარები კიდეებზე იგნორირდება.
3. დააჭირეთ «Change the key». კარიბჭე ქმნის ახალ გასაღებს, ხელახლა შიფრავს ყველა საიდუმლოს და აჩვენებს ბლოკს New recovery key გაფრთხილებით «The key is shown once. The old recovery key no longer works.»
4. შეინახეთ ახალი აღდგენის გასაღები. ღილაკი Download .txt ჩამოტვირთავს ფაილს bursu-pam-recovery-key.txt; ღილაკი Print გასაღებს ბეჭდავს. შეინახეთ სერვერისგან ცალკე.
5. მონიშნეთ «I have saved the new key» და დააჭირეთ «Done». მონიშვნის გარეშე კარიბჭე არ გააგრძელებს: «Tick “I have saved it” first.» შედეგი: «The encryption key is changed.»

რეჟიმის შეცვლა (Change the mode)

გვერდი /system/key/mode. რეჟიმი Protected by the OS-სა და Sealed-ს შორის გადაირთვება. საჭიროა ხელახალი დადასტურება, აღდგენის გასაღები და აკრეფილი სიტყვა; წუთში არაუმეტეს 5-ჯერ. სამიზნე რეჟიმი მიმდინარით განისაზღვრება: OS-რეჟიმიდან გვერდი Sealed-ში გადაჰყავს (Switch to sealed mode), Sealed-იდან — OS-რეჟიმში (Switch to OS-protected mode).

გვერდების ტექსტები: Sealed-ში გადასვლისას — «After this every restart of the gateway needs the passphrase you set here; until then nothing can connect.»; OS-რეჟიმში გადასვლისას — «After this the gateway opens the key at start by itself; the passphrase is no longer used.» შედეგი: «The key is now sealed. Keep the passphrase safe: every restart needs it.» ან «The key is now protected by the OS.»

თუ რეჟიმის შეცვლის შემდეგ დარჩა გასაღების ფაილები, რომელთა მოცილებაც ვერ მოხერხდა, გვერდი მათ ჩამოთვლის: «These key files hold the key without the passphrase and could not be deleted; delete them by hand:» (Sealed-ში გადასვლის შემდეგ) ან «The key file could not be written: after a restart the gateway will ask for the recovery key. Check the key directory's permissions:» (OS-რეჟიმში გადასვლის შემდეგ). პირველ შემთხვევაში ჩამოთვლილი ფაილები სერვერზე ხელით წაშალეთ; მეორეში შეამოწმეთ გასაღების კატალოგის უფლებები.

თუ გასაღების რეჟიმი შეიცვალა, სანამ გვერდი ღია იყო, კარიბჭე არაფერს აკეთებს და წერს: «The mode of the key changed after this page was opened, so nothing was done. Open the page again and check the current mode.»

თუ შეცვლის შედეგი უცნობია

თუ მონაცემთა ბაზამ ოპერაციის დასრულება არ დაადასტურა, გვერდი წერს: «The outcome of the key change is unknown — check the audit log and the key state; do not repeat the change until you are sure.» შემდეგ მოჰყვება განმარტება: «If the change did happen, the key held in the gateway's memory is out of date: restart the gateway (a sealed gateway then needs its passphrase) and check the key's state on the encryption key page and in the audit log.» გვერდზე ღილაკები გადაგიყვანთ Encryption key-ზე და აუდიტის ჟურნალში (Audit log). ნუ გაიმეორებთ შეცვლას, სანამ ჟურნალით არ დარწმუნდებით, რომ ის არ შესრულდა.

Status: კარიბჭის მდგომარეობა

გვერდი Status (მისამართი /system/status, მხოლოდ ადმინისტრატორი) მხოლოდ აჩვენებს კარიბჭის მდგომარეობას და არაფერს ცვლის. მინიშნება: «Read only. The certificate, the address and the trusted proxies are changed in gateway.json, then the service is restarted.» ზედა ნაწილში მითითებულია კონფიგურაციის სამუშაო ფაილის გზა: «Changed in gateway.json (… on this system), then a restart of the service. There is no certificate upload through the console in the first version.» სერტიფიკატის შეცვლა — თავში «კარიბჭის სერტიფიკატი».

ბლოკი «Gateway»

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

ბლოკი «Certificate»

სერვერები

სერვერი BURSU PAM-ში არის მანქანა ან მოწყობილობა, რომელსაც ადამიანები კარიბჭის გავლით უკავშირდებიან: Linux-სერვერი SSH-ით, Windows-სერვერი RDP-ით, ქსელური აღჭურვილობა Telnet-ით ან SSH-ით, სამუშაო მაგიდა VNC-ით, მონაცემთა ბაზა PostgreSQL, MySQL ან SQL Server. თითოეული სერვერისთვის კარიბჭე ინახავს მისამართს, პორტს, პროტოკოლს, საქაღალდეს და სერვერის შემოწმებულ «ანაბეჭდს» (ჰოსტის გასაღებს ან სერტიფიკატს). ლოგინები და პაროლები, რომლებითაც კარიბჭე სერვერზე შედის, ცალკე ინახება — ეს ანგარიშებია.

სერვერებთან მუშაობა კონსოლში მენიუს ჯგუფში Resources ხდება, პუნქტი Servers (მისამართი /servers). გვერდს ხედავს და ცვლის მხოლოდ Administrator. აუდიტორს (Auditor) ეს გვერდები არ უჩანს; ის მხოლოდ მოწყობილობების პროფილებს ხედავს.

სერვერმა კავშირები მხოლოდ კარიბჭისგან უნდა მიიღოს

კარიბჭე ამას თქვენ ნაცვლად ვერ გააკეთებს: ფაიერვოლის წესი თქვენს ქსელში კონფიგურირდება. კონსოლი სერვერის ხელმისაწვდომობას კარიბჭის მხრიდან ამოწმებს (ღილაკი Test the connection), მაგრამ არ ამოწმებს, დახურულია თუ არა სერვერი დანარჩენებისთვის. შეამოწმეთ ეს თავად: ჩვეულებრივი სამუშაო ადგილიდან სამიზნე სერვერთან კავშირი არ უნდა შედგეს.

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

სერვერების სია და საქაღალდეები

გვერდი Servers ორ ნაწილად არის დაყოფილი. მარცხნივ — საქაღალდეების ხე (Folders): სტრიქონი All servers და თქვენი საქაღალდეები, თითოეულში სერვერების რაოდენობით. მარჯვნივ — არჩეული საქაღალდის სერვერების ცხრილი; ცხრილის ზემოთ წერია საქაღალდის გზა და აღნიშვნა with subfolders: საქაღალდის არჩევისას ჩადგმული საქაღალდეების სერვერებსაც ხედავთ.

როცა საქაღალდეში სერვერები არ არის, კონსოლი წერს, რომ სერვერები ის მანქანებია, რომლებსაც კარიბჭის გავლით უკავშირდებიან, და გთავაზობთ შექმნათ პირველი სერვერი ან გადმოიტანოთ არსებულები ბრძანებით Move to folder.

საქაღალდეები

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

მენიუ Folder actions (სამი წერტილი ხის ზემოთ) ზედა დონის საქაღალდეს ქმნის (New folder). საქაღალდის სტრიქონის მენიუ (Actions for the folder …) შეიცავს:

საქაღალდესთან დაკავშირებული ყოველი მოქმედება აუდიტის ჟურნალში იწერება (folder.create, folder.rename, folder.move, folder.delete), გადატანა და წაშლა კი კარიბჭეს ღია სეანსების უფლებების ხელახლა შემოწმებასაც აიძულებს.

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

ღილაკი Create server ხსნის ფორმას /servers/new. შეცვლის ფორმა (/servers/<id>/edit) იგივეა. მასში ორი სექციაა: Main და State. ველების ნაწილი მხოლოდ გარკვეული პროტოკოლებისთვის ჩნდება — დანარჩენი დამალულია.

ფორმის ღილაკები: Create (შეცვლისას — Save), Reset (იმ მნიშვნელობების დაბრუნება, რომლებითაც ფორმა გაიხსნა), Cancel.

SSH-სერვერი

ეს ძირითადი შემთხვევაა: Linux, Unix, macOS, ასევე SSH-იანი ქსელური აღჭურვილობა. ველები საერთოა (იხ. ზემოთ); SSH-ს ცალკე ველები არ აქვს, გარდა არასავალდებულო Device profile-ისა. მოწყობილობის პროფილი აირჩიეთ მხოლოდ მაშინ, თუ სერვერის ანგარიშებისთვის საჭიროა პრივილეგირებული რეჟიმი (ბრძანება enable და მისთ.): მაშინ საჭიროა ქსელური მოწყობილობის ჩაშენებული პროფილი.

რა უნდა უჭერდეს მხარს სამიზნე SSH-სერვერი. კარიბჭე სამიზნეებს ალგორითმების ასეთი ნაკრებით უკავშირდება (სია კარიბჭეშია დაფიქსირებული და არ კონფიგურირდება):

• სერვერის ჰოსტის გასაღები: ECDSA nistp256 / nistp384 / nistp521, RSA SHA-512-ით ან SHA-256-ით (rsa-sha2-512, rsa-sha2-256). Ed25519 გასაღებს კარიბჭე არ იღებს: სერვერს, რომელსაც მხოლოდ Ed25519 ჰოსტის გასაღები აქვს, კარიბჭე ვერ შეამოწმებს;
• გასაღებების გაცვლა: ECDH nistp384 / nistp256, Diffie-Hellman group16-sha512 / group14-sha256;
• შიფრები: AES-256-GCM და AES-256-CTR; შეტყობინების ავთენტიფიკაციის კოდები HMAC-SHA2-256 და HMAC-SHA2-512; შეკუმშვის გარეშე.

მუშაობისას კარიბჭის მხრიდან სერვერთან ერთი კავშირი იმართება თითო სეანსზე. ჰოსტის გასაღების დადასტურებამდე ამ სერვერზე სეანსები არ იხსნება: სერვერის გვერდზე წერია Not confirmed — sessions are refused until it is.

ჰოსტის გასაღების მიღებისა და დადასტურების შესახებ დაწვრილებით — ქვეთავში SSH ჰოსტის გასაღები. ანგარიშების პაროლით და პირადი გასაღებით შესვლა აღწერილია თავში ანგარიშები.

Telnet-სერვერი

Telnet-სერვერისთვის:

• სავალდებულოა Device profile: ის აღწერს, როგორ ცნობს კარიბჭე მოწყობილობის მოთხოვნებს და როგორ შეჰყავს ლოგინი და პაროლი (იხ. მოწყობილობების პროფილები). თუ პროფილი არ არის არჩეული: A Telnet server needs a device profile. Telnet-ის არჩევისას კონსოლი ნაგულისხმევ პროფილს თავად სვამს (Generic Unix);
• ანგარიშები შედიან მხოლოდ პაროლით. თუ სერვერს უკვე აქვს პირადი გასაღებიანი ანგარიშები, მისი Telnet-ზე გადართვა შეუძლებელია: This server has key accounts; a Telnet server signs in with a password only. Delete them first.;
• Telnet-ს სერვერის იდენტობა არ აქვს, ამიტომ ჰოსტის გასაღები არ არის და დასადასტურებელი არაფერია (Not checked — Telnet has none);
• შესაქმნელად საჭიროა ველის The password crosses the network between the gateway and this server in clear text მონიშვნა და ვინაობის დადასტურება. თუ ველი არ არის მონიშნული: Tick the acknowledgement to use Telnet. თუ ვინაობის დადასტურება არ არის: Confirm who you are before making this server use Telnet. უკვე არსებული Telnet-სერვერის შენახვა ამას ხელახლა არ მოითხოვს.

სიაში და ბარათზე Telnet-სერვერს აქვს ნიშნული Not encrypted to the server.

RDP-სერვერი

კარიბჭე სერვერზე RDP-სეანსს პაროლიანი ანგარიშის სახელით ხსნის, მომხმარებელი კი კარიბჭეს თავისი RDP-კლიენტით უკავშირდება (ფაილი .rdp შეიძლება ჩამოიტვირთოს გვერდზე «My access», იხ. ჩემი წვდომა).

ფორმის ცალკე ველები:

კიდევ პირობები:

• RDP-სერვერის ანგარიშები შედიან მხოლოდ პაროლით. თუ გასაღებიანი ანგარიშებია: This server has key accounts; an RDP server signs in with a password only. Delete them first.;
• RDP-სერვერი გათიშული იქმნება, სანამ მისი სერტიფიკატი არ დადასტურდება: კონსოლი შეგახსენებთ Saved, but the server is inactive: confirm the RDP server's certificate.;
• სამიზნეზე TLS-იანი RDP უნდა მუშაობდეს: კარიბჭე TLS/CredSSP (NLA) დონის დაცვას იყენებს; RDP-ის «სტანდარტულ» დაცვას (TLS-ის გარეშე) კარიბჭე არ იყენებს. თუ სერვერი მხოლოდ მას გვთავაზობს, შემოწმება იტყვის: The server offers no TLS: only the old RDP security, which the gateway does not use.

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

VNC-სერვერი

VNC-ისთვის ფორმაზე აუცილებლად აირჩიეთ, როგორ შედის კარიბჭე სერვერზე (ველი Sign-in to the server). ნაგულისხმევი მნიშვნელობა არ არის: არჩევანს ადამიანი აკეთებს. ექვსი ვარიანტი:

ოთხი სუსტი ტიპისთვის (ცხრილის 3–6 სტრიქონები) ფორმაში ჩნდება ველი I understand and accept this კონკრეტული საფრთხის შესახებ ტექსტთან ერთად. ველის გარეშე: Tick the box to accept the weak connection to this server. ვინაობის ახალი დადასტურების გარეშე: Confirm who you are before making this server use a weak connection. თუ სხვა ტიპს აირჩევთ, მონიშვნა მოიხსნება.

სამი რამ ზუსტად უნდა იცოდეთ:

• VNC-სერვერის ანგარიშები შედიან მხოლოდ პაროლით; გასაღებები მხარდაჭერილი არ არის (This server has key accounts; a VNC server signs in with a password only. Delete them first.). ტიპებისთვის «TLS, no sign-in» და «No sign-in (not encrypted)» ანგარიში პაროლის გარეშე იქმნება (ანგარიშის ტიპი No sign-in);
• თუ შესვლის ტიპს ცვლით, არსებული ანგარიშები კი მას არ შეესაბამება: An account of this server does not fit the new sign-in type. Change or delete it first.;
• ნებისმიერი TLS-ტიპის VNC-სერვერი გათიშული იქმნება: A VNC server with a TLS sign-in type stays inactive until its certificate is confirmed after saving.

მომხმარებლის კარიბჭესთან VNC-ით დაკავშირება სხვაგვარად არის მოწყობილი: კლიენტი შედის ერთჯერადი კოდით კონსოლიდან ან BURSUcm-იდან (თავი VNC-ით დაკავშირება).

მონაცემთა ბაზების სერვერები: PostgreSQL, MySQL, SQL Server

მონაცემთა ბაზებისთვის კარიბჭე პროქსის როლს ასრულებს: მომხმარებელი თავისი კლიენტით (psql, DBeaver, SSMS და მისთ.) კარიბჭეს უკავშირდება და პაროლის ნაცვლად «საშვს» (pass) შეიყვანს. კარიბჭე ბაზაზე სერვერის ანგარიშით თავად შედის. ის შედის მხოლოდ SQL-ლოგინითა და პაროლით; Windows-ით შესვლა (SSPI), Entra ID და სერტიფიკატით შესვლა მხარდაჭერილი არ არის.

პროტოკოლების სიაში ბაზას ჰქვია PostgreSQL, MySQL ან SQL Server. MariaDB-სთვის ცალკე პუნქტი არ არის: MariaDB-სერვერი, რომელიც MySQL-ის პროტოკოლით მუშაობს, აირჩევა როგორც MySQL.

რა არის მნიშვნელოვანი:

• კარიბჭე ბაზასთან კავშირს ყოველთვის შიფრავს (TLS) და ამოწმებს ბაზის სერტიფიკატის გასაღების «ანაბეჭდს» (SPKI SHA-256). სანამ ანაბეჭდი არ დადასტურდება, სერვერი არააქტიურია: A database server stays inactive until its certificate is confirmed. გამონაკლისი — PostgreSQL ჩართული «Allow an unencrypted connection»-ით: სერტიფიკატი არ არის და დასადასტურებელი არაფერია;
• ბაზების ანგარიშები შედიან მხოლოდ პაროლით: This server has key accounts; a database server signs in with a password only. Delete them first.;
• «მხოლოდ წაკითხვის» წვდომისთვის თავად ბაზაზე შექმენით მომხმარებელი მინიმალური უფლებებით და დაამატეთ ის სერვერის ცალკე ანგარიშად. სერვერის ბარათი გიკარნახებთ, როგორ (PostgreSQL-ისთვის: როლი მხოლოდ CONNECT-ითა და SELECT-ით; MySQL-ისთვის: SELECT სქემაზე; SQL Server-ისთვის: ლოგინი როლით db_datareader);
• ადამიანის ლოგინი, სერვერის სახელი და ანგარიშის სახელი ერთად კლიენტისთვის მომხმარებლის სახელს ქმნის. თუ ის ბაზის პროტოკოლისთვის ზედმეტად გრძელია, საშვის გაცემა შეუძლებელია: The person's login, the server and the account together are too long for this database protocol. Shorten the server or account name.

სერვერის ბარათი

სერვერის სახელზე დაჭერა ბარათს ხსნის (/servers/<id>). სათაურში — ღილაკები Edit და Delete, გათიშულ სერვერს გვერდით მდგომარეობის ნიშნული აქვს. ჩანართები:

სერვერის წაშლა (Delete) დადასტურებას ითხოვს: Delete the server … and its N accounts with their secrets? Rules that name it directly stop leading to it. ანგარიშები და მათი საიდუმლოებები სერვერთან ერთად იშლება, წესები, რომლებიც სერვერს პირდაპირ ასახელებდა, მისკენ აღარ მიმართავს (წესში დარჩება «Nowhere», თუ სხვა არაფერია არჩეული). ამ სერვერზე ღია სეანსები მაშინვე წყდება.

SSH ჰოსტის გასაღები: როგორ მივიღოთ, დავადასტუროთ და რა იცვლება

ჰოსტის გასაღები SSH-სერვერის «პასპორტია». კარიბჭე მას პირველი გაცნობისას იმახსოვრებს (მეთოდი «ნდობა პირველი გამოყენებისას», TOFU) და შემდეგ ყოველი დაკავშირებისას ამოწმებს, რომ სერვერმა იგივე გასაღები წარადგინა. თუ გასაღები შეიცვლება (სერვერის ჩანაცვლება, ხელახალი ინსტალაცია), კარიბჭე დაკავშირებაზე უარს იტყვის და ანგარიშის საიდუმლო ასეთ სერვერზე არ გაიგზავნება.

1. გახსენით სერვერის ბარათი. სანამ გასაღები არ არის დადასტურებული, ბლოკში Host key წერია Not confirmed — sessions are refused until it is, სერვერების სიაში კი სახელთან დგას ნიშნული Key not confirmed.
2. დააჭირეთ «Test the connection». კარიბჭე სერვერის მისამართსა და პორტს დაუკავშირდება (არაუმეტეს 20 წამისა), წაიკითხავს წარდგენილ გასაღებს და აჩვენებს ბლოკს Connection check ანაბეჭდით სტრიქონში Presented host key. თუ სიაში Sign in as ანგარიში აირჩიეთ, კარიბჭე შესვლას სცდის; ვარიანტი Key only, no sign-in ნიშნავს «მხოლოდ გასაღების წაკითხვას». შესვლა სრულდება მხოლოდ უკვე დადასტურებულ გასაღებზე — წინააღმდეგ შემთხვევაში კარიბჭე პაროლს არ გაგზავნის: Confirm the key first; the sign-in is tested against a confirmed key only.
3. შეადარეთ ანაბეჭდი. კონსოლი გიკარნახებთ: Before confirming, compare it with ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub on the server itself. ანუ თავად სერვერზე შეასრულეთ ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub (RSA-სთვის — ssh_host_rsa_key.pub) და შეადარეთ სტრიქონი SHA256:… კონსოლის ნაჩვენებს. კარიბჭე ECDSA გასაღებს ანიჭებს უპირატესობას; თუ სერვერს ის არ აქვს, ნაჩვენები იქნება RSA გასაღები — მაშინ შეადარეთ ssh_host_rsa_key.pub-ს. ყოველთვის შეადარეთ იმავე ტიპის გასაღებს, რომელიც კარიბჭემ აჩვენა.
4. დააჭირეთ «Confirm this key». კარიბჭე სერვერს ხელახლა დაუკავშირდება და გასაღებს მხოლოდ მაშინ შეინახავს, თუ სერვერი სწორედ მას წარადგენს. თუ ამ დროში სერვერმა სხვა გასაღები აჩვენა: The server now presents another key than the one you checked. Check again. წარმატების შემდეგ: Host key confirmed. SSH გასაღების დადასტურება პაროლის ხელახლა შეყვანას არ მოითხოვს, მაგრამ აუდიტში იწერება (hostkey.confirm).

დადასტურების შემდეგ შემოწმების შედეგი ასე იკითხება:

რა იცვლება, როცა გასაღები ჩამოიყრება: სერვერის მისამართის (Address) ან პორტის შეცვლისას დადასტურებული გასაღები იშლება და კონსოლი წერს Saved. The host or port changed: confirm the host key again. მისამართის ან პორტის შეცვლის შემდეგ ნაბიჯები 2–4 ხელახლა გაიარეთ. SSH პროტოკოლის «წინასწარ დადასტურება» შეუძლებელია: გასაღების დადასტურება მხოლოდ მისი დანახვის შემდეგ შეიძლება.

სერტიფიკატები და ანაბეჭდები: RDP, VNC და მონაცემთა ბაზები

TLS-იანი სერვერებისთვის კარიბჭე სერტიფიკატის «ანაბეჭდს» ისევე ამოწმებს, როგორც SSH ჰოსტის გასაღებს: პირველი გაცნობისას მას ადმინისტრატორს აჩვენებენ, ადმინისტრატორი მას თავად სერვერთან ადარებს და ადასტურებს, ამის შემდეგ კი კარიბჭე მხოლოდ მას იღებს. შეჯამება:

სერტიფიკატის დადასტურება სერვერს ავტომატურად არ რთავს. Confirm this certificate-ის შემდეგ კონსოლი წერს Certificate confirmed. Switch the server on to use it.; ჩართეთ გადამრთველი Active ბარათზე (ღილაკი Active ბლოკში Quick actions) ან შეცვლის ფორმაში.

სერტიფიკატი ხელახლა დასტურდება (კარიბჭე ამას თავად გეტყვით), თუ სერვერის მისამართი, პორტი ან პროტოკოლი შეცვალეთ, VNC-ისთვის კი — შესვლის ტიპიც. ამ დროს დადასტურებული ჩანაწერი იშლება და სერვერი ითიშება: Saved. The address, port or protocol changed: check the connection and confirm the certificate again. (VNC-ისთვის: Saved. The address, port or sign-in type changed, so the confirmed certificate was removed.). აღწერის, საქაღალდის ან სახელის უბრალო შეცვლა სერტიფიკატს არ ეხება.

RDP

1. დაუშვით NTLM სერვერისთვის. ამის გარეშე შემოწმება უარს ამბობს: Not checked: this RDP server is not marked as allowing NTLM, and in this version an RDP server is reached with NTLM only.
2. გახსენით ბარათი და დააჭირეთ «Test the connection». ღილაკის მინიშნება: Connects and shows the server's TLS certificate; no sign-in is tried. კარიბჭე უკავშირდება, გადის დაცვის შეთანხმებას და TLS-ხელჩამორთმევას და შემდეგ არაფერს აგზავნის: არც პაროლს, არც სააღრიცხვო მონაცემებს. ნაჩვენებია Presented certificate.
3. შეადარეთ ანაბეჭდი. კონსოლი: Before confirming, compare it with the SHA-256 fingerprint of the Remote Desktop certificate on the server itself. Windows-სერვერზე, მაგალითად, PowerShell-ში:

   $c = Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' | Select-Object -First 1
   ([BitConverter]::ToString([Security.Cryptography.SHA256]::Create().ComputeHash($c.RawData)) -replace '-','').ToLower()

   შეადარეთ თექვსმეტობითი ციფრები, რეგისტრსა და გამყოფებს მნიშვნელობა არ აქვს. თუ საცავში რამდენიმე სერტიფიკატია, შეადარეთ იმას, რომელსაც დისტანციური სამუშაო მაგიდების სერვისი იყენებს.
4. დააჭირეთ «Confirm this certificate». კონსოლი ვინაობის დადასტურებას მოგთხოვთ (ხელახალი პაროლი და კოდი), შემდეგ სერვერს ხელახლა დაუკავშირდება და სერტიფიკატს მხოლოდ მაშინ შეინახავს, თუ სერვერმა ზუსტად ის წარადგინა. წინააღმდეგ შემთხვევაში: The server now presents another certificate than the one you checked. Check again. მოვლენა აუდიტში იწერება (rdp.cert.confirm).
5. ჩართეთ სერვერი (Active).

შემოწმების შედეგი: Matches the confirmed certificate — სერვერმა დადასტურებული სერტიფიკატი წარადგინა; Differs from the confirmed certificate … — წარდგენილია სხვა (სერტიფიკატის განახლება ან ჩანაცვლება; ხელახლა დაადასტურეთ მხოლოდ შემოწმების შემდეგ). შემოწმების შეცდომები: The server offers no TLS: only the old RDP security, which the gateway does not use, The server did not answer as an RDP server, The TLS handshake with the server failed, The server could not be reached (იხ. გაუმართაობები).

ღილაკი Clear the certificate (ვინაობის დადასტურებისა და მოთხოვნის Clear the confirmed certificate of …? The server is switched off until a certificate is confirmed again. შემდეგ) დადასტურებას მოხსნის და სერვერს გათიშავს. გამოიყენეთ ის, როცა სერტიფიკატის იძულებით ხელახლა დადასტურებაა საჭირო (მაგალითად, სერვერზე ახალი გამოუშვეს).

VNC

VNC-ისთვის ბარათზე არის ბლოკი Check connection და ბლოკი Server certificate (Subject, Public key (SHA-256), Confirmed …). თუ სერტიფიკატი არ არის დადასტურებული, წერია Not confirmed. This server cannot be used until its certificate is confirmed.

1. დააჭირეთ «Check connection». მინიშნება: Shows what the server offers and its certificate; it signs in only with an account, and on a TLS server only once its certificate is confirmed. შემოწმების ნაბიჯები ქვემოთ ცხრილშია ჩამოთვლილი.
2. შეადარეთ სერტიფიკატი იმას, რომელიც თავად VNC-სერვერზეა დაყენებული (Before confirming, compare the certificate's SHA-256 fingerprint with the certificate on the VNC server itself.). კონსოლი სერტიფიკატის საჯარო გასაღების SHA-256-ს აჩვენებს.
3. დააჭირეთ «Confirm this certificate» (საჭირო იქნება ვინაობის დადასტურება). სერტიფიკატი მაგრდება, თუ სერვერმა ზუსტად ის წარადგინა. შეტყობინება: The certificate is pinned. Switch the server on to use it.
4. ჩართეთ სერვერი.

შესვლის შესამოწმებლადაც, სიაში Also sign in with the account აირჩიეთ ანგარიში; ვარიანტი Offered types only, no sign-in ნიშნავს «მხოლოდ სერვერის შეთავაზებების წაკითხვას». ანგარიშის საიდუმლო იგზავნება მხოლოდ დადასტურებულ სერტიფიკატზე (TLS-სერვერებისთვის) ან დაუშიფრავ სერვერზე, თუ ეს რისკი მიიღეთ. შესვლის სუსტი ტიპებისთვის შესვლამდე ვინაობის დადასტურება მოითხოვება (Confirm who you are before the gateway signs in to this server.).

თითოეული ნაბიჯის მდგომარეობა: ok, failed, skipped, not reached. თუ ნაბიჯი ვერ შესრულდა, კონსოლი მიზეზს ხსნის (მიზეზების სია — თავში გაუმართაობები). ღილაკი Clear the certificate მიმაგრებას მოხსნის და სერვერს გათიშავს (The certificate pin was removed and the server switched off.).

თუ ამ სერვერისთვის VNC-სეანსის მუშა პროცესი ავარიულად სრულდება, ბარათზე ჩნდება გაფრთხილება: The session worker for this server crashed N times in the last 24 hours.

მონაცემთა ბაზები

მონაცემთა ბაზის სერვერის ბარათზე შემოწმების ღილაკს ჰქვია Check connection (მინიშნება: Connects and shows the server's certificate and version; no sign-in is tried). კარიბჭე აჩვენებს Subject, Issuer, Valid, Key (SPKI SHA-256), Certificate SHA-256 და სერვერის ვერსიას (Server version). დადასტურება — ღილაკი Confirm this certificate (უკვე დადასტურებულის ჩასანაცვლებლად — Confirm the new certificate), პაროლისა და კოდის ხელახალი შეყვანით. ანაბეჭდის თავად სერვერზე, სერტიფიკატის ფაილით შესადარებლად შეგიძლიათ შეასრულოთ: openssl x509 -in server.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256.

• თუ სერვერი დადასტურებულისგან განსხვავებულ გასაღებს აჩვენებს: The server now shows a different certificate key. Connections are refused until you confirm it.
• თუ PostgreSQL-ს ჩართული აქვს რეჟიმი «დაშიფვრის გარეშე», სერვერი კი მართლაც არ გვთავაზობს დაშიფვრას: The server offers no encryption; it is reached unencrypted, as the switch on its form allows.
• SQL Server თავისი «სარეზერვო» სერტიფიკატით: This is SQL Server's own fallback certificate: it changes at every service start, and each restart needs a new confirmation. Provision a certificate (mssql-conf set network.tlscert on Linux, SQL Server Configuration Manager on Windows). დააყენეთ სერვერზე მუდმივი სერტიფიკატი, წინააღმდეგ შემთხვევაში ყოველი გადატვირთვის შემდეგ ხელახლა დადასტურება მოგიწევთ.

ღილაკი Test sign-in არჩეული ანგარიშის შესვლას ამოწმებს (სია Sign in as). მინიშნება: Signs in with the stored password of the account you choose; you are asked to confirm who you are first. შედეგი: The account signed in. ან The account could not sign in: … მოკლე მიზეზით (მიზეზების სია — თავში გაუმართაობები). პაროლი იგზავნება მხოლოდ დადასტურებულ სერტიფიკატზე ან (PostgreSQL დაშიფვრის გარეშე) დაცულ SCRAM-გაცვლაში.

ლიცენზიის ლიმიტი აქტიურ სერვერებზე

კარიბჭის ლიცენზია აქტიური სერვერების რაოდენობას ზღუდავს. ლიმიტს ზემოთ აქტიური სერვერის შექმნა, გათიშულის ჩართვა ან ფორმის ისე შენახვა, რომ სერვერი აქტიური გახდეს, შეუძლებელია: The licence allows N active servers. Switch off a server or extend the licence. უარი აუდიტის ჟურნალში იწერება (licence.limit). სერვერის გათიშვა ყოველთვის შეიძლება. ლიცენზიის მდგომარეობა და მისი გაგრძელება — გვერდზე Licence (თავი «ლიცენზია»).

თუ ლიცენზიას ვადა გაუვიდა, ლიცენზია არ არის ან აქტიური სერვერები დაშვებულზე მეტია, საშეღავათო ვადა კი დასრულდა, კონსოლი ცვლილებებზე საერთოდ უარს ამბობს (მათ შორის სერვერებისაზე), მაგალითად: The licence has ended: changes are refused. Upload a licence on Settings → Licence. სრული სია — თავში გაუმართაობები.

სერვერები, რომლებიც «მარაგად» შექმენით, ჯობია გათიშული იყოს: არააქტიური სერვერები ლიმიტს არ ხარჯავს.

რა ემართება ღია სეანსებს სერვერის შეცვლისას

სერვერის შენახვის, გათიშვის, სხვა საქაღალდეში გადატანის ან წაშლის შემდეგ, ასევე მისი სერტიფიკატის წაშლის შემდეგ, კარიბჭე ყველა ღია სეანსის (SSH, RDP, VNC და ბაზებზე) უფლებებს ხელახლა ამოწმებს. სეანსი, რომლის უფლებებიც გაქრა (სერვერი გათიშულია ან წაშლილია, სერტიფიკატი მოხსნილია), იხურება მომხმარებლისთვის გასაგები შეტყობინებით. სახელის ან აღწერის შეცვლა ღია სეანსებს არ ეხება.

სერვერის ნებისმიერი ცვლილება აუდიტის ჟურნალში იწერება: server.create, server.update, server.delete, server.test (კავშირის შემოწმება, შედეგით), hostkey.confirm, rdp.cert.confirm, rdp.cert.clear, vnc.cert.confirm, vnc.cert.clear, server.db_tls_pin, server.db_test. მოვლენებში პაროლები და გასაღებები არ არის; Telnet-ის შემოწმებისთვის მხოლოდ მიღწეული ნაბიჯები ფიქსირდება.

მოწყობილობების პროფილები

მოწყობილობის პროფილი კარიბჭისთვის «მინიშნებების» ნაკრებია: როგორ შევიდეს Telnet-სერვერზე და როგორ ჩართოს პრივილეგირებული რეჟიმი ქსელურ მოწყობილობაზე. Telnet-ს შესვლის ერთიანი პროცედურა არ აქვს: თითოეული მოწყობილობა საკუთარ მოთხოვნას წერს («Username:», «login:», «Password:») და შეცდომას თავისებურად აცნობებს. პროფილი აღწერს, რომელი სტრიქონები უნდა ამოიცნოს კარიბჭემ, რომ ლოგინი და პაროლი დროულად შეიყვანოს.

პროფილების გვერდები მენიუს ჯგუფ Resources-შია, პუნქტი Device profiles (/servers/profiles). Administrator პროფილებს ხედავს და ცვლის. Auditor პროფილების სიასა და ბარათებს მხოლოდ წასაკითხად ხედავს: ასე აუდიტორს შეუძლია შეამოწმოს, რა წესებით შედის კარიბჭე მოწყობილობებზე. შექმნის, შეცვლის, წაშლის, დუბლირებისა და ტრანსკრიპტზე შემოწმების ღილაკები მას არ უჩანს.

პროფილების სია

ცხრილი შეიცავს სვეტებს Name (ჩაშენებულებთან ნიშნით Built-in), Line end sent და Wait per step, seconds. ღილაკი New profile საკუთარ პროფილს ქმნის; ღილაკი Edit სტრიქონში მხოლოდ საკუთარ პროფილებს აქვს. გვერდის მინიშნება: How the gateway signs in on a Telnet server, and enters privileged mode on a network device.

ჩაშენებული პროფილები კარიბჭესთან ერთად მოდის, განახლებები მათ ინახავს, მათი შეცვლა ან წაშლა შეუძლებელია (Built-in profiles are kept by updates and cannot be changed; duplicate one to adapt it.). ისინი ექვსია:

პროფილის ბარათი და კოპირება

პროფილის ბარათი (/servers/profiles/<id>) მის ყველა ველს აჩვენებს: Name, User name prompt, Password prompt, Signed-in prompt, Refused login, Wait per step, seconds, Line end sent, ჩაშენებულებს კი დამატებით Privileged step, User name suffix, Fixed answers. სტრიქონი Servers using it ჩამოთვლის სერვერებს, რომლებიც პროფილს იყენებენ.

ღილაკი Duplicate ქმნის ასლს სახელით «Copy of …» (თუ ასეთი სახელი დაკავებულია — «Copy of … 2», «Copy of … 3» და ა. შ.) და მას შესაცვლელად ხსნის. პრივილეგირებული ნაბიჯი, მომხმარებლის სახელის სუფიქსი და ფიქსირებული პასუხები კოპირებისას არ გადადის: ისინი მხოლოდ ჩაშენებულ პროფილებშია ხელმისაწვდომი. კონსოლი ამის შესახებ აფრთხილებს: Privileged mode is available only with the built-in profile. ამიტომ ასლი გამოდგება ჩვეულებრივი მოწყობილობებისთვის ლოგინითა და პაროლით შესვლით; მოწყობილობისთვის, რომელსაც პრივილეგირებული რეჟიმი სჭირდება, ჩაშენებული პროფილი გამოიყენეთ.

ღილაკი Delete საკუთარ პროფილზე გეკითხებათ Delete profile …?. პროფილს, რომელსაც ერთი სერვერი მაინც იყენებს, ვერ წაშლით: The profile is used by these servers: … ჩაშენებულ პროფილს ვერ წაშლით: A built-in profile cannot be changed or deleted.

საკუთარი პროფილის შექმნა და შეცვლა

ღილაკი New profile ხსნის ფორმას /servers/profiles/new. შაბლონების მნიშვნელობები რეგულარული გამოსახულებებია. კარიბჭე მათ ბოლო მიღებული სტრიქონის დასასრულზე იყენებს და ადარებს უსაფრთხო ალგორითმით, რომელიც «მძიმე» გამოსახულებებზე არ იყინება.

მინიშნება შაბლონების ქვემოთ: A .NET regular expression, at most 512 characters, matched at the end of the last line. Backreferences, lookarounds and atomic groups are not supported. შაბლონის შესაძლო შეცდომები: This is not a valid regular expression., At most 512 characters., Backreferences, lookarounds and atomic groups are not supported., This regular expression is too costly to check against device output. Simplify its repetitions. ღია ფორმაში ცვლილებები «დაკარგული განახლებისგან» არის დაცული: თუ პროფილი სხვა ადმინისტრატორმა შეცვალა, იქნება The record was changed by another administrator — open it again.

პროფილის შემოწმება ტრანსკრიპტზე

პროფილის ფორმის ქვემოთ (და ბარათზე) არის ბლოკი Test against a transcript: ჩასვამთ იმას, რასაც მოწყობილობა აჩვენებს, კარიბჭე კი ამოწმებს, შევიდოდა თუ არა ამ პროფილით. შემოწმებისთვის მოწყობილობასთან დაკავშირება საჭირო არ არის და ნამდვილი პაროლები არ გამოიყენება. მინიშნება: Paste what the device shows; mark where the gateway types with ⟨user⟩ and ⟨password⟩, or paste a TelnetProbe capture.

1. დააკოპირეთ მოწყობილობის გამონატანი ველში Transcript: მოთხოვნები და პასუხები, როგორც ადამიანი ხედავს.
2. მონიშნეთ ადგილები, სადაც კარიბჭე მონაცემებს შეიყვანს, მარკერებით ⟨user⟩ (სახელი) და ⟨password⟩ (პაროლი). პრივილეგირებული ნაბიჯისთვის — ⟨privileged⟩. თითოეული მარკერის წინ კარიბჭე მოკლე პაუზას აკეთებს (200 მწმ).
3. დააჭირეთ «Run the test». კარიბჭე ტრანსკრიპტს «ვირტუალურ დროში» გაითამაშებს და აჩვენებს ცხრილს: Step, Pattern, Matched text, Result თითოეული ნაბიჯისთვის (User name prompt, Password prompt, Signed in, Refused, Privileged password prompt, Privileged mode, Fixed answer; გვერდით — ტრანსკრიპტის სტრიქონის ნომერი). თითოეული ნაბიჯის შედეგი: Matched, Not matched, Timed out ან Skipped.
4. წაიკითხეთ შედეგი: The gateway would sign in with this profile. ან The gateway would not sign in with this profile.

ტრანსკრიპტი 64 კიბ-ზე მეტი ვერ იქნება (A transcript is at most 64 KiB.); ცარიელი ან წაუკითხავი ტრანსკრიპტი იძლევა A value was not accepted. Check the form. შემოწმებიდან არაფერი ინახება. ფორმიდან შემოწმება პროფილის შენახვამდეც შეიძლება: ის იყენებს შაბლონებს, რომლებიც ფორმაში შეიყვანეთ. ბარათიდან შემოწმება შენახულ შაბლონებს იყენებს. შემოწმების გაშვება მხოლოდ Administrator-ს შეუძლია.

ანგარიშები

სერვერის ანგარიში არის ლოგინი და საიდუმლო (პაროლი ან პირადი გასაღები), რომლებითაც კარიბჭე სერვერზე ადამიანის ნაცვლად შედის. ადამიანმა საიდუმლო არ იცის და ვერც გაიგებს: კარიბჭე მას დაკავშირების მომენტში თავად სვამს. ერთ სერვერს შეიძლება რამდენიმე ანგარიში ჰქონდეს (მაგალითად, root და deploy). რომელია მათგან ადამიანისთვის ხელმისაწვდომი, წესები წყვეტს.

ანგარიშებს ხედავს და ცვლის მხოლოდ Administrator. ისინი ორ ადგილას არის ხელმისაწვდომი: სერვერის ბარათის ჩანართზე Accounts (ერთი სერვერის ანგარიშები) და საერთო სიაში Accounts მენიუს ჯგუფში Resources (/accounts, ყველა სერვერის ანგარიშები — მოსახერხებელია ლოგინით ძებნისთვის).

ანგარიშების სია

გვერდი /accounts (მინიშნება: Every account of every server, to find one by login. Secrets are write-only.):

ანგარიშის შექმნა

ღილაკი Add account სერვერის ბარათის ჩანართზე Accounts ხსნის ფორმას /accounts/new (საერთო სიაში /accounts შექმნის ღილაკი არ არის — სია მხოლოდ ძებნისთვის, საიდუმლოების შეცვლისა და წაშლისთვისაა). სერვერი, რომლის ბარათიდანაც მოხვედით, უკვე არჩეულია.

საიდუმლოს ველების ქვემოთ კონსოლი წერს: The old secret cannot be viewed. The new one is stored encrypted; the change goes into the audit log. ღილაკები: Create, Cancel. შექმნის შემდეგ სერვერის ბარათის ჩანართზე Accounts ბრუნდებით. აუდიტში იწერება მოვლენა account.create (ლოგინი, სერვერი, საიდუმლოს ტიპი, რეჟიმი; თავად საიდუმლო არ იწერება).

პირადი გასაღებები: რომელი გამოდგება

• გასაღებების ტიპები: RSA და ECDSA (nistp256/384/521). Ed25519 ჯერ მხარდაჭერილი არ არის: Ed25519 keys are not supported yet. Use an ECDSA or RSA key. შექმენით შესაფერისი გასაღები: ssh-keygen -t ecdsa -b 384 ან ssh-keygen -t rsa -b 4096.
• ფორმატები: OpenSSH (BEGIN OPENSSH PRIVATE KEY) და PEM. დაშიფრული PKCS#8-ის (BEGIN ENCRYPTED PRIVATE KEY) წაკითხვა შეუძლებელია; კონსოლი გირჩევთ: Convert the key to the OpenSSH format with ssh-keygen -p -f <file> and paste it again.
• თუ საიდუმლო ფრაზა არასწორია ან გასაღები სხვა ტიპისაა: This key cannot be used: the passphrase is wrong, or it is not an RSA or ECDSA key. თუ ველი ცარიელია ან მასში გასაღები არ არის: A private key in OpenSSH or PEM format is required.
• გასაღებით შესვლა შეიძლება SSH-სერვერებზე. Telnet-ის, RDP-ის, VNC-ისა და ბაზების სერვერები მხოლოდ პაროლს იღებენ (იხ. შეტყობინებები თავში სერვერები).

საიდუმლოს შეცვლა

სტრიქონის მენიუ → Replace secret ხსნის გვერდს /accounts/<id>/secret (ღილაკი Replace). მასზე ნაჩვენებია მხოლოდ საიდუმლოს ტიპი და ბოლო შეცვლის თარიღი, თავად საიდუმლო არ ჩანს. შეიყვანეთ ახალი პაროლი (ორჯერ) ან ახალი გასაღები საიდუმლო ფრაზით იმავე წესებით. შენახვის შემდეგ: The secret is replaced. აუდიტში იწერება account.secret საიდუმლოს ტიპით (password ან key), მნიშვნელობების გარეშე. შეცვლა უკვე ღია სეანსებს არ წყვეტს: ისინი ძველი შესვლით გრძელდება, ახლები კი ახალ საიდუმლოს იყენებს.

VNC-სერვერების ანგარიშებს პაროლის ველის ქვემოთ განმარტება აქვს: ტიპებისთვის «VNC password» მნიშვნელოვანია მხოლოდ პირველი 8 სიმბოლო; «Mac user name and password»-ისთვის სახელი და პაროლი თითოეული არაუმეტეს 63 ბაიტია (For a Mac, the name and the password are each at most 63 bytes.).

ქსელური მოწყობილობის პრივილეგირებული რეჟიმი

მარშრუტიზატორებსა და კომუტატორებზე შესვლის შემდეგ ხშირად პრივილეგიების «ამაღლებაც» არის საჭირო: Cisco-ზე — ბრძანებით enable და მეორე პაროლით, Huawei-ზე — super-ით. კარიბჭეს შეუძლია ეს ნაბიჯი თავად შეასრულოს, რომ ადამიანმა მეორე პაროლი არ იცოდეს. რეჟიმი ანგარიშისთვის ირთვება შექმნისას ან გვერდზე /accounts/<id>/privileged (ღილაკი Save privileged mode) და ხელმისაწვდომია მხოლოდ თუ სერვერს ქსელური მოწყობილობის ჩაშენებული პროფილი აქვს არჩეული (Cisco IOS / IOS-XE, Cisco NX-OS, Huawei VRP). წინააღმდეგ შემთხვევაში: Privileged mode is available only with a built-in network-device profile.

სერვერის პროფილის ჩანაცვლება ისეთით, რომელსაც პრივილეგირებული ნაბიჯი არ აქვს, შეუძლებელია, სანამ პრივილეგირებულ რეჟიმში მყოფი ანგარიშები არსებობს: Accounts of this server use privileged mode: choose a built-in network-device profile, or turn their privileged mode off first. რეჟიმის შეცვლა აუდიტში იწერება (account.privileged: რა იყო და რა გახდა); პრივილეგირებული რეჟიმის პაროლი არ იწერება.

როგორ არის ანგარიშები დაკავშირებული სერვერებთან და წესებთან

• ანგარიშის ლოგინი არის ის, რასაც წესი ველში Logins ასახელებს. წესი უშვებს შესვლას «ჩამოთვლილი ლოგინებიდან ნებისმიერით, არჩეული სერვერებიდან ნებისმიერზე».
• თუ სერვერს ადამიანისთვის ერთი ხელმისაწვდომი ანგარიში აქვს, მას შეუძლია დაკავშირებისას ის არ მიუთითოს; თუ რამდენიმე — სახელს მესამე ნაწილს უმატებს (ლოგინი:სერვერი:ანგარიში, იხ. თავი SSH-ით დაკავშირება).
• სერვერის წაშლა მის ანგარიშებს საიდუმლოებებთან ერთად შლის. ანგარიშის წაშლა წესებს არ ცვლის, მაგრამ ისინი ამ ლოგინით შესვლას აღარ უშვებს.
• თუ კარიბჭე დახურულია (დაშიფვრის გასაღები ღია არ არის, იხ. ლუქის მოხსნა), საიდუმლოს შექმნა ან შეცვლა შეუძლებელია: The encryption key is not available.

წვდომის წესები

წესი პასუხობს კითხვას «ვის, სად, რომელი ანგარიშით, რა ვადით და მონაცემებზე რა უფლებებით». წესის გარეშე არანაირი წვდომა არ არსებობს: თუ ვერცერთი წესი ვერ ასახელებს ადამიანსა და სერვერს, დაკავშირება შეუძლებელია. ფორმულა კონსოლიდან: A rule = who × where × with which account × until when.

წესებს ხედავს და ცვლის მხოლოდ Administrator (მენიუს ჯგუფი Access, პუნქტი Access rules, მისამართი /rules). წესი ორი ტიპისაა:

• Standing access (მუდმივი წვდომა) — მოქმედებს მაშინვე და ვადის ბოლომდე. დაწვრილებით აქ არის აღწერილი.
• By request (მოთხოვნით) — ადამიანი შეზღუდული დროით მოთხოვნას აგზავნის, წყვეტენ დამმტკიცებლები. ეს ტიპი აღწერილია თავში წვდომის მოთხოვნები. ის იყენებს იმავე ჩამონათვალს «ვინ», «სად», «ანგარიშები» და «მონაცემებზე უფლებები», რომელიც ქვემოთ არის აღწერილი.

წესების სია

ცხრილი /rules აჩვენებს სვეტებს Name, Type, Users, Groups, Servers, Accounts (All ან Specified (N)), Data (მოკლედ: ფაილები, ტერმინალი, ასლები), Starts / Ends და State. ფილტრ-ჩიპები: In effect, Ending ≤ 7 d, Not started yet, Expired, Disabled. ძებნა: Name, user, server. ღილაკი Create rule წესს ქმნის. ჯგუფური მოქმედებები მონიშნულ მუდმივ წესებზე: Enable, Disable, Delete.

წესის მდგომარეობები სვეტში State: In effect, Ends in N d (მალე დასრულდება), Not started yet, Expired, Disabled. ცარიელი სია: No access rules yet და განმარტება, რომ წესი ამბობს, ვის შეუძლია რომელ სერვერებს დაუკავშირდეს, რომელი ანგარიშებით და რა ვადამდე.

წესის შექმნა და შეცვლა

ღილაკი Create rule ხსნის ფორმას /rules/new. ზედა ნაწილში ტიპის გადამრთველია: Standing access / By request (მინიშნება: Standing access applies at once. By request lets people ask for a limited time; approvers decide.). წესის ტიპი შექმნისას აირჩევა და შემდეგ აღარ იცვლება (The type of a rule is chosen when it is created and cannot be changed.). შეცვლის ფორმა (/rules/<id>/edit) იგივეა. სექციები რიგითობით არის დანომრილი:

ფორმის ღილაკები: Create / Save, Reset, Cancel. დროის წესები მარტივია: მხოლოდ «დან» და «მდე». განმეორებადი ფანჯრები («სამუშაო დღეებში 9-დან 18-მდე») წესებში არ არის; ერთჯერადი სამუშაოებისთვის ვადა მიუთითეთ, პერიოდულისთვის — შექმენით წესები საჭირო ინტერვალებზე ან გამოიყენეთ წვდომა მოთხოვნით.

წესის ბარათი

სახელწოდებაზე დაჭერა ბარათს ხსნის (/rules/<id>). სათაური — სახელწოდება, მდგომარეობის ნიშნული, ღილაკები Edit და Delete. ჩანართები:

თუ წესში დარჩა «არავინ» ან «არსად» (Nobody / Nowhere) — მაგალითად, ჯგუფი ან სერვერი წაშალეს, — კონსოლი აფრთხილებს: This rule names nobody or nowhere (its group, user or server was deleted), so it gives no access. Edit it to name them, or delete it.

რა ემართება ღია სეანსებს

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

• წესს ვადა გაუვიდა, გაითიშა ან წაიშალა; ადამიანი გაითიშა ან მისი როლები მოიხსნა; ჯგუფი შეიცვალა ან წაიშალა; სერვერი გაითიშა ან წაიშალა; ანგარიში წაიშალა; საქაღალდე გადაიტანეს ან წაშალეს; ადამიანმა პაროლი შეცვალა (პირდაპირი SSH-კავშირებისთვის) — სეანსი იხურება, ადამიანი ხედავს შეტყობინებას (მაგალითად, Your access to this server has ended. The session is closed.);
• თუ წვდომას რამდენიმე წესი იძლევა, სეანსი მანამ ცოცხლობს, სანამ ერთი მაინც მოქმედებს; კარიბჭე წვდომას ხელახლა ამოწმებს და «პირველ» წესს არ მიჰყვება;
• წესი შეავიწროვეს (მოაცილეს ფაილების ან გაცვლის ბუფერის მიმართულება, გამორთეს მოწყობილობა ან შეყვანა): შევიწროება მაშინვე მოქმედებს, ღია სეანსი ახალ უფლებებს შემდეგი პაკეტიდან იღებს. თუ SSH-სეანსს ტერმინალი წესით აქვს გამორთული, გარსი და ბრძანებები იხურება შეტყობინებით Your access rule no longer allows a terminal on this server. The session is closed., ფაილების გადაცემა კი ხელმისაწვდომი რჩება;
• წესი გააფართოვეს (დაამატეს მოწყობილობა ან მიმართულება): RDP-მოწყობილობას, რომელიც დაკავშირებისას არ იყო შეთავაზებული, მიმდინარე სეანსში ვერ დაამატებთ — გაფართოება შემდეგი დაკავშირებიდან მოქმედებს (A device the session did not offer when it started cannot be added to it: a change that allows more takes effect at the next connection.);
• მოთხოვნით გაცემული წვდომისთვის ადამიანი დასრულებამდე რამდენიმე წუთით ადრე გაფრთხილებას ხედავს, გაუქმებისას კი — ვინ გააუქმა წვდომა.

ვადით დახურვა ზუსტია: ყოველი სეანსისთვის კარიბჭე ტაიმერს აყენებს იმ წესის უახლოეს დასასრულზე, რომელიც მას წვდომას აძლევს. თუ კარიბჭის მონაცემთა ბაზა დროებით მიუწვდომელია, ღია სეანსები გრძელდება (შემოწმებაზე უარი «არად» არ ითვლება), ახლები კი არ იხსნება.

წესის წაშლა (Delete) გეკითხებათ: Delete the rule …? The access it gives ends at once. მოთხოვნით წესს, რომელსაც უკვე აქვს მოთხოვნები, ვერ წაშლით — მისი მხოლოდ გათიშვა შეიძლება (A rule that has requests cannot be deleted; disable it instead.). წესების ყველა ცვლილება აუდიტში იწერება (rule.create, rule.update, rule.enable, rule.disable, rule.extend, rule.delete) იმის აღწერით, რა შეიცვალა.

ფაილების, გაცვლის ბუფერისა და მოწყობილობების პოლიტიკა

ეს უფლებები წვდომის წესში, Data movement განყოფილებაში დგინდება. ისინი პასუხობს კითხვას «რისი წაღება შეუძლია ადამიანს სერვერიდან და რისი მოტანა მასზე» და მოქმედებს ყოველ სეანსზე. ველები ყველა პროტოკოლისთვის საერთოა; რომელი მათგანი რომელ პროტოკოლს ეხება, ცხრილი აჩვენებს.

ველები და ნაგულისხმევი მნიშვნელობები

როგორ ერთიანდება წესები

თუ ადამიანს წვდომას რამდენიმე წესი აძლევს, საბოლოო უფლებები მათი გაერთიანებაა: ფაილებისა და გაცვლის ბუფერის მიმართულებებისთვის — მიმართულებების გაერთიანება, Terminal-ისთვის, ასლებისთვის, ბუფერის ტექსტის ჩაწერისთვის, RDP-ის მოწყობილობებისა და ეკრანის მართვისთვის — «ჩართულია ერთ წესში მაინც». ასლები ინახება, თუ ამას რომელიმე წესი მოითხოვს, ხოლო ზღვრულ ზომად აიღება უდიდესი იმ წესებიდან, სადაც ასლები ჩართულია. შედეგი შესვლისას განისაზღვრება, სეანსის განმავლობაში ინახება და ხელახლა გამოითვლება, როცა წესები იცვლება (იხ. რა ემართება ღია სეანსებს).

USB RDP-ში

USB-ის გადამისამართება მოწყობილობას მთლიანად გადასცემს (დისკების ჩათვლით) და ფაილების წესს არ ემორჩილება. ამიტომ მისი ჩართვა მხოლოდ Upload and download-თან ერთად შეიძლება: USB devices can be allowed only together with “Upload and download” for files. ველის მინიშნება: USB redirection moves whole devices, drives included, and does not follow the file rule. It can be switched on only together with “Upload and download” for files.

SFTP და SCP: რით განსხვავდება ტერმინალისგან

• ფაილების გადაცემა ცალკე არხით მიმდინარეობს, რომელსაც კარიბჭე თავად აანალიზებს: ყოველი ოპერაცია მიმართულების მიხედვით მოწმდება, იწარმოება ჟურნალი (გვერდი ფაილების გადაცემა), გამოითვლება გადაცემული მონაცემების ჰეში, საჭიროების შემთხვევაში ინახება ასლი.
• ფაილის ზომასა და სეანსის საერთო მოცულობას ზღუდავს პარამეტრები Sessions → File transfer (Largest file, MB, All files in one session, MB). გადაჭარბება გადაცემას აჩერებს.
• თუ წესი ტერმინალს არ უშვებს, მუშაობს მხოლოდ sftp და scp; გარსი, ბრძანებები, rsync და sftp -s უარყოფილია. SCP WinSCP-ის რეჟიმში სერვერზე გარსს მოითხოვს და ამიტომ ისიც უარყოფილია (WinSCP უნდა გადაერთოს SFTP-ზე).
• Telnet-სერვერებისთვის ფაილების გადაცემა მიუწვდომელია.

ტიპური სქემები: მხოლოდ ფაილები — Terminal გამორთულია, File transfer — «Upload and download» ან ერთი მიმართულება; მხოლოდ გარსი — Terminal ჩართულია, ფაილები გამორთულია (გახსოვდეთ შეზღუდვა 1); RDP მონაცემების გატანის გარეშე — გაცვლის ბუფერი, ფაილები და მოწყობილობები გამორთულია (სერვერის ხმის დატოვება შეიძლება).

რას ხედავს მომხმარებელი უარის დროს, ჩამოთვლილია თავში გაუმართაობები (ჯგუფი «ფაილების გადაცემა»). როგორ დაუკავშირდეს მომხმარებელი SFTP-ითა და SCP-ით, აღწერილია განყოფილებაში SFTP-ითა და SCP-ით დაკავშირება.

პარამეტრები: კარიბჭის SSH გასაღები

გვერდი /system/ssh (მენიუ System → Settings → ფილა Gateway SSH key, ჯგუფი «Security»). მას მხოლოდ Administrator ხედავს. ეს მხოლოდ წასაკითხი გვერდია: მასზე პარამეტრები არ არის, კოპირების ღილაკების გარდა. გვერდის მინიშნება: The key SSH clients see when they connect to the gateway. BURSUcm and OpenSSH remember it on first use.

ეს თავად კარიბჭის გასაღებია (ის, რასაც ადამიანების SSH-კლიენტები ხედავენ), და არა რომელიმე სამიზნე სერვერის გასაღები — სერვერების გასაღებები აღწერილია განყოფილებაში სერვერები. კარიბჭე მას ერთხელ ქმნის, პირველი გახსნისას, და იყენებს ტიპს ECDSA nistp256.

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

პარამეტრები: .rdp ფაილების ხელმოწერა

გვერდი /system/rdp-signing (ფილა RDP file signing, ჯგუფი «Security»). მას მხოლოდ Administrator ხედავს და ცვლის. გვერდის სათაური — Signing of .rdp files.

როცა ადამიანი .rdp ფაილს «My access» გვერდიდან ჩამოტვირთავს (იხ. ჩემი წვდომა), კარიბჭეს შეუძლია მისი ხელმოწერა. ხელმოწერილი ფაილი Remote Desktop-ში აჩვენებს, ვინ გამოსცა იგი, ხოლო ნებისმიერი ხელმოწერილი სტრიქონის შეცვლა ხელმოწერას არღვევს (A signed .rdp file shows Remote Desktop who published it, and a change to any signed line breaks the signature. The certificate must be trusted on the computers that open the file.). ხელმოწერის გარეშე Remote Desktop ადამიანს ფაილის ყოველი გახსნისას აფრთხილებს: There is no signing key: .rdp files are not signed, and Remote Desktop warns the person who opens one.

რომელი სერტიფიკატი გამოდგება. ფაილი არაუმეტეს 64 კიბ-ისა; შიგნით ზუსტად ერთი სერტიფიკატია RSA-ს დახურული გასაღებით, არანაკლებ 2048 ბიტისა; სერტიფიკატი ციფრულ ხელმოწერას უშვებს (გაფართოება «გასაღების გამოყენება» ან არ არის, ან შეიცავს digitalSignature-ს); მოქმედების ვადა უკვე დაიწყო და ჯერ არ დასრულებულა. ატვირთვისას კარიბჭე თავად აწერს ხელს საცდელ ფაილს და ამოწმებს ხელმოწერას; თუ გასაღები სერტიფიკატს არ შეესაბამება, ის მაშინვე იქნება უარყოფილი და არა ყოველი ჩამოტვირთვისას. უარის მიზეზები — შეცდომების ცხრილში ქვემოთ და თავში გაუმართაობები.

გასაღების შენახვა და წაშლა აუდიტის ჟურნალში მოვლენით rdp.signing_key იწერება (ანაბეჭდი; უარისას — მიზეზი). სერტიფიკატის ვადის მოახლოებული ამოწურვა მიმოხილვის გვერდის გაფრთხილებებში გამოჩნდება.

პარამეტრები: სეანსები

გვერდი /system/sessions (ფილა Sessions, ჯგუფი «Sessions and protocols»). მას მხოლოდ Administrator ხედავს და ცვლის. გვერდის მინიშნება: How sessions through the gateway are recorded and how long they may stay idle. Input recording, idle time and the banner apply to new sessions only; running sessions keep theirs.

გვერდი ერთი ფორმაა ღილაკებით Save და Reset. ყველა მნიშვნელობა ერთდროულად ინახება; ყოველი შეცვლილი მნიშვნელობა აუდიტის ჟურნალში მოვლენით setting.change იწერება (წინა და ახალი მნიშვნელობა). თუ რედაქტირების დროს ფორმა სხვა ადმინისტრატორმა შეინახა, გამოჩნდება The record was changed by another administrator — open it again.; გახსენით გვერდი ხელახლა. არასწორი რიცხვი: Enter a whole number from … to ….

რომელი ცვლილებები მოითხოვს ვინაობის დადასტურებას

ცვლილება, რომელიც ზედამხედველობას ასუსტებს ან კონფიდენციალურობას ეხება, ვინაობის ხელახალ დადასტურებას მოითხოვს (პაროლისა და კოდის განმეორებით შეყვანა, 10 წუთი). გამკაცრებადი ცვლილებები დადასტურებას არ მოითხოვს.

• SSH-ის შეყვანის ჩაწერის ჩართვა (Recording what people type needs your password and code again.);
• RDP-ში კლავიშების დაჭერის ჩაწერის ჩართვა (Recording keystrokes needs your password and code again.) ან აკრეფილი ტექსტის ინდექსის ჩართვა (Indexing typed text needs your password and code again.);
• ჩანაწერების შენახვის ვადის შემცირება; SSH-ის უმოქმედობის დროის გაზრდა; RDP-სეანსის ხანგრძლივობის ზღვრის გაზრდა ან მოხსნა; RDP-ის უმოქმედობის დროის გაზრდა; ფაილის ზომისა და სეანსის ჯამის ზღვრის გაზრდა ან მოხსნა; ასლების შენახვის ვადის შემცირება;
• ბანერის ტექსტის შეცვლა (any change of the banner's text), რადგან ნებისმიერმა სხვა ტექსტმა შეიძლება ფრაზა «სეანსი იწერება» მოაშოროს.

სხვა შემთხვევებში: Confirm who you are before this change: … It lowers session protection. და ბმული Confirm who I am.

პარამეტრები: VNC

გვერდი /system/vnc (ფილა VNC, ჯგუფი «Sessions and protocols»). მას მხოლოდ Administrator ხედავს და ცვლის. მინიშნება: Limits for VNC sessions through the gateway. A change applies to new sessions only; running sessions keep theirs.

მსმენელი (Listener)

პირველი ბლოკი აჩვენებს, მზად არის თუ არა კარიბჭე VNC-კლიენტების კავშირების მისაღებად. ის მხოლოდ წასაკითხია: The listener is set in the gateway's configuration file (vncListen and vncAdvertisedName) and is changed there; it cannot be changed here. ველები: State, Host (სახელი, რომელსაც კარიბჭე კლიენტებს ასახელებს — vncAdvertisedName), Port.

ლიმიტები და პარამეტრები

მნიშვნელობა დიაპაზონის გარეთ: Enter a whole number from … to …. ზღვრების გაზრდა, რომელიც დაცვას ასუსტებს (სეანსების რაოდენობა, უმოქმედობის დრო, ხანგრძლივობა, ბუფერის ზომა, კავშირის დამყარებისა და განახლების ლიმიტები, ექსპორტების რაოდენობა, მაყურებლის მეხსიერება), და კოდის მისამართზე მიბმის გამორთვა ვინაობის დადასტურებას მოითხოვს: Confirm who you are before weakening a limit. ხანგრძლივობის ზღვრის მოხსნაც (0) შესუსტებაა. ჩვენებისა და ექსპორტის პარამეტრები — კადრების სიხშირე, ხანგრძლივობა და ზომა — ამ სიას არ ეხება. შენახვის შემდეგ: Saved.

პარამეტრები: მონაცემთა ბაზები

გვერდი /system/databases (ფილა Databases, ჯგუფი «Sessions and protocols»). მას მხოლოდ Administrator ხედავს და ცვლის. მინიშნება: Limits, pass lifetimes and protections for database connections through the gateway. A change applies to passes and connections made after the save; ones already open keep what they started with.

მონაცემთა ბაზების მომხმარებელი «My access» გვერდზე იღებს «საშვს» (pass) და კლიენტში მას პაროლად შეიყვანს (იხ. მონაცემთა ბაზებთან დაკავშირება). საშვი ერთხელ ჩანს, მაგრამ ერთჯერადი არ არის: მოქმედების ვადაში მისით რამდენიმე კავშირის გახსნა შეიძლება (ნაგულისხმევად 8 საათი, არაუმეტეს 16 კავშირისა), ხოლო პირველი კავშირი ჩვენებიდან 2 წუთში უნდა დამყარდეს. პარამეტრები ადგენს საშვების სიცოცხლის ხანგრძლივობას, კავშირების რაოდენობას და დაცვას.

ახალი მნიშვნელობები მოქმედებს შენახვის შემდეგ შექმნილ საშვებსა და კავშირებზე; უკვე ღია კავშირები წინა მნიშვნელობებს ინარჩუნებს. ცვლილებები აუდიტში მოვლენით db.settings იწერება (ცვლილებები და შესუსტებების სია). ზღვრის გაზრდა, ვადის გახანგრძლივება, დაცვის გამორთვა (channel binding, Strict), მოთხოვნის ტექსტის შემცირება და ვერსიის სტრიქონის შეცვლა შესუსტებებია: These changes weaken protection and need you to confirm your password: … და ბმული Confirm who I am. ორი ადმინისტრატორის მიერ ერთდროული რედაქტირებისას: The record was changed by another administrator — open it again.

წვდომის მოთხოვნები

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

როგორ არის ეს მოწყობილი

• წესს «მოთხოვნით» (By request) ადმინისტრატორი ქმნის განყოფილებაში წვდომის წესები. თავისთავად ის არაფერს უშვებს. ის მხოლოდ განსაზღვრავს: ვის აქვს მოთხოვნის უფლება, რომელ სერვერებსა და ანგარიშებზე, ვინ ამტკიცებს, რამდენი დამტკიცებაა საჭირო, რა ვადით შეიძლება მოთხოვნა და რამდენ ხანს უნდა ველოდოთ გადაწყვეტილებას.
• მოთხოვნა — ეს არის კონკრეტული ადამიანის თხოვნა კონკრეტული სერვერის კონკრეტულ ანგარიშზე წვდომის შესახებ მითითებული ვადით. მოთხოვნას ყოველთვის აქვს მიზეზი (ტექსტი) და ზოგჯერ ტიკეტის ნომერი.
• წვდომა ჩნდება, როცა მოთხოვნა დამტკიცებულია (ან ავტომატურად დამტკიცებულია, თუ წესი ასეა მორგებული). კარიბჭე თავად წერს ცალკე ნებართვას ამ ვადით. მისი შეცვლა შეუძლებელია: ის ან თავის ვადაზე დასრულდება, ან გაუქმდება.

მოთხოვნის მდგომარეობები

მოთხოვნა ვებ-კონსოლში

გვერდი /access/requests იხსნება მენიუდან My access (ჩანართი Access requests). მას ხედავს ნებისმიერი შესული მომხმარებელი. გვერდი ორ ჩანართად იყოფა: Available to request და My requests.

ჩანართი «Available to request»

ცხრილი აჩვენებს ყველაფერს, რისი მოთხოვნაც შეგიძლიათ. სვეტები: Server, Account, Limits (უდიდესი ვადა, მაგალითად Up to 8 h), Approval და Access period (დროის ფანჯარა, რომელშიც წესი საერთოდ უშვებს წვდომას, თუ ის შეზღუდულია).

სვეტში Approval წერია ორიდან ერთი:

• Approvals needed: N და ქვემოთ Approvers who can decide: M — რამდენი დამტკიცებაა საჭირო და რამდენ ადამიანს აქვს ახლა მათი მიცემის უფლება.
• Granted at once; the reason is recorded — წესი ავტომატურია: წვდომა მოთხოვნისთანავე გაიცემა, მაგრამ მიზეზი მაინც იწერება.

სტრიქონის ბოლოს — ღილაკი Request access. თუ ამ წყვილზე უკვე გაქვთ მოლოდინში მყოფი მოთხოვნა, ღილაკის ნაცვლად დგას ნიშანი Request pending. თუ ადმინისტრატორმა ამ წყვილზე გადაუდებელი წვდომა დაგიშვათ, გვერდით არის წითელი ღილაკი Emergency access (იხ. გადაუდებელი წვდომა).

ფანჯარა «Request access»

ფანჯარა იხსნება ღილაკით Request access. ზემოთ წერია: Server …, account ….

ღილაკი Send request მოთხოვნას აგზავნის. შედეგი — შეტყობინება გვერდის ზემოთ: Request … sent. (დაელოდეთ გადაწყვეტილებას) ან Request … sent and approved automatically. (წესი ავტომატურია, წვდომა უკვე გაცემულია).

რას ამოწმებს კარიბჭე გაგზავნისას

• არაუმეტეს 10 მოლოდინში მყოფი მოთხოვნისა ერთ ადამიანზე. მეტი — უარი You have too many requests waiting. Wait for a decision or cancel one.
• თუ იმავე წყვილზე უკვე გაქვთ მოლოდინში მყოფი მოთხოვნა, მეორე არ იქმნება: კარიბჭე აჩვენებს შეტყობინებას You already have a request waiting for this server account. და პირველზე მიგითითებთ.
• თუ ისედაც გაქვთ დაკავშირების უფლება მთელი მოთხოვნილი ინტერვალის განმავლობაში, მოთხოვნა უარყოფილია: You already have access to this server account for that whole period.
• თუ ადამიანები, რომლებსაც დამტკიცება შეუძლიათ, კვორუმისთვის საჭიროზე ნაკლებია, მოთხოვნა არ მიიღება: Nobody can approve this request now. Contact the administrator. თქვენ თავად საკუთარი მოთხოვნის დამმტკიცებლად არასოდეს ითვლებით.
• თუ წყვილზე რამდენიმე წესი მოქმედებს, მთავრად ყველაზე მკაცრი ითვლება: ჯერ საჭირო დამტკიცებების უდიდესი რაოდენობით, შემდეგ უმცირესი ვადით, შემდეგ — ყველაზე ძველი.
• თუ სერვერი იმ რაოდენობას აღემატება, რომელზეც ლიცენზიაა ნაყიდი, ან ლიცენზიის ვადა ამოიწურა, მოთხოვნა არ მიიღება (შეტყობინებები This server is beyond the number of servers the gateway's licence allows. Contact the administrator. და The gateway's licence has ended. Contact the administrator.).

უარი აუდიტის ჟურნალში იწერება როგორც მოვლენა request.create შედეგით «უარყოფილია». შეტყობინებების სია — თავში გაუმართაობები.

ჩანართი «My requests»

თქვენი მოთხოვნები, ახლები ზემოთ. სვეტები: No., Server, Requested, Access period, State. სტრიქონის ქვეშ ჩანს, ვინ და როდის გადაწყვიტა (Decided by …), ხოლო თუ წვდომა გაუქმდა — ვინ და რატომ (Revoked by …: …). სანამ მოთხოვნა ელოდება, ნაჩვენებია, რომელ საათამდე უნდა დაელოდოთ: Decision due by …. ცარიელი სია: You have made no requests.

როცა ჩანართს My requests ხსნით, ყველა გადაწყვეტილი მოთხოვნა ნანახად აღინიშნება და ზარში მათ შესახებ შეტყობინება ქრება (Your requests that were decided: …).

როდის სრულდება ან უქმდება წვდომა

• თავის ვადაზე. წვდომა მოქმედებს ზუსტად დამტკიცებული ინტერვალის განმავლობაში. მისი დასრულებისას კარიბჭე ხურავს სეანსებს, რომლებიც ამ წვდომას ეყრდნობოდა.
• გაფრთხილება. დასრულებამდე რამდენიმე წუთით ადრე (ნაგულისხმევად 5, კონფიგურირდება გვერდზე Notifications, 0–30; 0 გამორთავს) კარიბჭე ღია SSH-სეანსში წერს სტრიქონს Your granted access ends in … minutes. File an extension request if you need more time. კლიენტი BURSUcm იგივე გაფრთხილებას ამომხტარი შეტყობინებით აჩვენებს.
• გაუქმება. წვდომის ვადამდე შეწყვეტის უფლება აქვთ: თავად მომთხოვნს (Release access), ადმინისტრატორს (გვერდი /rules/grants, სათაური Grants) და ამ წესის დამმტკიცებელს (ჩანართი Active grants გვერდზე Approvals). ამ წვდომაზე დაფუძნებული სეანსები მაშინვე იხურება, ტერმინალში იწერება Your granted access was revoked by …. The session is closed. გახანგრძლივებები, რომლებიც გაუქმებულ წვდომაზე იყო დამოკიდებული, გამოითხოვება (მოლოდინში მყოფი) ან ასევე უქმდება (დამტკიცებული).
• წესი გამორთეს. მასზე ყველა მოლოდინში მყოფი მოთხოვნა გამოითხოვება, რის შესახებაც წერილი მოდის. უკვე გაცემული წვდომა ამ დროს რჩება, თუ ადმინისტრატორმა არ მონიშნა Also revoke access already granted from this rule.

თუ ჩვეულებრივი SSH-ით უკავშირდებით

თუ წვდომა ახლა არ არის, მაგრამ მისი მოთხოვნა შეიძლება, კარიბჭე კავშირზე უარს ამბობს და თავად გიჩვენებთ გზას: Access is not allowed now. You can request it in the web console: … (კონსოლის მისამართით) ან, თუ კონსოლის მისამართი მითითებული არ არის, … under My access, Access requests. გააგზავნეთ მოთხოვნა გვერდზე /access/requests და დამტკიცების შემდეგ ხელახლა დაუკავშირდით.

მოთხოვნა BURSUcm-იდან

კლიენტს BURSUcm (Windows და Universal) შეუძლია მოთხოვნების გაგზავნა და მათთვის თვალყურის დევნება ვებ-კონსოლის გარეშე. საჭიროა, რომ კარიბჭე კატალოგის წყაროდ იყოს მიერთებული (იხ. BURSUcm).

• კავშირების ხეში ჩნდება მეორე ძირი On request. იქ ჩამოთვლილია სერვერები, რომლებზეც წვდომა არ არის, მაგრამ მისი მოთხოვნა შეიძლება. ყოველ სტრიქონს აქვს განმარტება Access to this server is given on request. მდგომარეობას ხატულები ასახავს: მოლოდინი, Approved. Access starts … (დამტკიცებულია, მოგვიანებით დაიწყება), ან until HH:mm მოქმედი წვდომისთვის.
• ორმაგი დაწკაპუნება ან პუნქტი Request access... ხსნის ფანჯარას Request access (გახანგრძლივებისას მას ჰქვია Extend access). ველები იგივეა, რაც კონსოლში: Server (მხოლოდ წასაკითხი), Account (სია, თუ ანგარიში რამდენიმეა), Start (When approved ან At a set time თარიღით წწწწ-თთ-დდ და დროით სს:წწ), Duration (ვარიანტით Custom... და მინიშნებით minutes, 1 to …), Reason მთვლელით, Ticket (ან Ticket (optional)) და Format: …. ღილაკები: Cancel, წითელი Emergency access (მხოლოდ თუ გადაუდებელი წვდომა დაშვებულია) და Send request.
• ფანჯრის სათაურის ქვეშ კლიენტი წერს, როგორ განიხილება მოთხოვნა: Approved automatically; the request is recorded. ან Approvals needed: N. People who can approve: M., და ქვემოთ Rule: ….
• გაგზავნის შემდეგ იგივე ფანჯარა მდგომარეობის პანელად იქცევა: Waiting for approval · X of Y approved · expires …, Approved · starts …, Approved · active until …, ასევე შედეგის სტრიქონები This access has ended., The request was denied., The request was cancelled., Nobody answered in time; the request expired., The access was revoked. პანელის ღილაკებია Cancel request და Connect now (როცა წვდომა მოქმედებს). თუ კარიბჭე მიუწვდომელია, პანელი წერს cannot reach the gateway, trying again და გამოკითხვას იმეორებს; თუ გამოკითხვა შეწყდა — The status is no longer updated. Open My access requests to see it.
• მენიუ File → My access requests... ხსნის თქვენი მოთხოვნების სიას (სათაური My access requests, მინიშნება Your requests, newest first. A running access can be given back or extended.) სვეტებით Server, Account, State, Period, Answers და ღილაკებით Refresh, Release, Extend..., Cancel request, Close. წვდომის დაბრუნებისას კლიენტი კითხულობს: Give this access back now? Sessions running on it end. ცარიელი სია: You have no access requests yet. Ask for access from the On request list.
• მოთხოვნის ეტაპები კლიენტში: Waiting for approval, Scheduled, Active, Ended, Denied, Cancelled, Expired, Revoked.
• ამომხტარი გაფრთხილება დასრულებამდე: Your access to … as … ends at …. Extend it in My access requests. დასრულების შემდეგ: Your access to … as … has ended. წვდომის მაშინვე ხელახლა მოთხოვნის შესაძლებლობით.

კლიენტი ველებს გაგზავნამდე თავად ამოწმებს და გასაგებ შეტყობინებებს აჩვენებს: A reason is required., The reason must be at most 1000 characters., Enter the ticket number., The ticket number must be at most 64 characters., The duration must be from 1 minute to …, The start must be later than now., The start can be at most 7 days ahead., The period must lie inside the time this access may be requested for. კარიბჭის პასუხები იმავე ფრაზებით ჩანს, რაც კონსოლში (იხ. გაუმართაობები).

მოთხოვნების დამტკიცება

განყოფილება Approver როლის მქონე ადამიანებისთვის. ის აღწერს გვერდს /approvals (მენიუ Access → Approvals), რომელზეც დამმტკიცებელი წვდომის მოთხოვნებზე იღებს გადაწყვეტილებებს და ადასტურებს ბრძანებებს, რომლებიც ბრძანებების კონტროლმა შეაჩერა. დამმტკიცებლის სამუშაო დღის ზოგადი წესრიგი — განყოფილებაში როლი «Approver».

ვის შეუძლია დამტკიცება

მოთხოვნის გადაწყვეტა შეუძლია ადამიანს, რომელიც ერთდროულად:

• ჩართულია და აქვს როლი Approver;
• «მოთხოვნით» ტიპის წესში დამმტკიცებლადაა დასახელებული — პირადად ან ჯგუფის მეშვეობით (წესის ველი Approvers);
• არ არის ამ მოთხოვნის ავტორი. საკუთარ მოთხოვნაზე გადაწყვეტილების მიღება შეუძლებელია: გვერდი მას უბრალოდ არ აჩვენებს.

თუ მოთხოვნის გადაწყვეტა თქვენ არ შეგიძლიათ ან ის არ არსებობს, გვერდი ერთნაირად პასუხობს — «ვერ მოიძებნა» (HTTP 404). ასე დამმტკიცებელი ვერ იგებს სხვის მოთხოვნებზე, რომლებზეც დაშვებული არ არის. ადმინისტრატორი გვერდს Approvals ვერ ხედავს: როლები Administrator და Approver შეუთავსებელია (დაწვრილებით — განყოფილებაში როლი «Approver»).

გვერდის ჩანართები

ჩანართები ასეთი თანმიმდევრობით მიდის. ყოველი სია 100 სტრიქონით არის შეზღუდული.

გვერდითა მენიუს ნიშანზე რიცხვი მხოლოდ გადაწყვეტილების მომლოდინე მოთხოვნებს ითვლის. დადასტურების მომლოდინე ბრძანებები მასში არ შედის; მათ შესახებ გვამცნობს ჩანართი Commands და ზარი.

მოთხოვნის ბარათი

სათაური — Request №. ბარათში: Requester, Server and account, Access period, Reason, Ticket, Rule, Approvals: X of Y და Decisions so far (ვინ უკვე დაამტკიცა ან უარყო, კომენტარებით; სანამ არავინაა — None yet.). შესაფასებლად დამატებულია ორი ცნობა: This person's last five requests და This person's last five sessions on this server.

თუ მოთხოვნის გაგზავნის შემდეგ წესის პირობები შეიცვალა, ღილაკების ზემოთ დგას გაფრთხილება იმის შესახებ, რა მოხდება დამტკიცებისას: … now governs this access, so approving will cancel this request., No rule offers this access any more, so approving will cancel this request., The ticket no longer meets the rule's terms, so approving will cancel this request. ან The rule now allows at most … minutes: the grant will be that long.

დამტკიცება ან უარყოფა

შედეგები: Your approval is recorded; more approvals are needed. (კვორუმი ჯერ არ შეგროვილა), Approved. The access is granted. (კვორუმი შეგროვდა, წვდომა გაიცა), Request denied.

კვორუმი. საჭირო დამტკიცებების რაოდენობას წესი ადგენს (1-დან 5-მდე, სხვადასხვა ადამიანისგან). მოთხოვნა წვდომას იღებს, როცა შეგროვდება დამტკიცებების საჭირო რაოდენობა იმ ადამიანებისგან, რომლებსაც ამ მომენტისთვის ჯერ კიდევ აქვთ დამტკიცების უფლება. თუ ხმის მიმცემთაგან ვინმეს უკვე ჩამოართვეს როლი ან წესიდან ამოიღეს, მისი ხმა არ ითვლება; ისტორიაში ეს ჩანს, როგორც Vote dropped: this approver no longer qualified at the final count. როცა დამმტკიცებლებმა სხვადასხვა ვადა შემოგვთავაზეს, გაიცემა შემოთავაზებულთაგან ყველაზე მოკლე.

მოლოდინი. თუ მოთხოვნა წესით განსაზღვრულ დროში (ნაგულისხმევად 240 წუთი) არ გადაწყდა, მისი ვადა გადის.

ჩანართი «Active grants»

ყოველი წვდომისთვის ჩანს ადამიანი, სერვერი, ანგარიში და ვადა. ღილაკი Revoke კითხულობს Revoke the access of … to …? Open sessions end at once. და იღებს არასავალდებულო ველს Reason (kept in the log) (არაუმეტეს 1000 სიმბოლოსი). გაუქმება ღია სეანსებს ხურავს, ხოლო ამ წვდომაზე დამოკიდებული გახანგრძლივებები გამოითხოვება ან უქმდება. შეტყობინებები: Access revoked. და Access revoked, and … extension(s) that depended on it. თუ წვდომა უკვე დასრულდა ან გაუქმდა, ნათქვამი იქნება This access has already ended or was taken back.

ბრძანებების დადასტურება

თუ ბრძანებების კონტროლის პოლიტიკა შეიცავს წესს Ask a second person, მომხმარებლის მიერ აკრეფილი სტრიქონი შეჩერებულია, სანამ დამადასტურებელი მას არ დაუშვებს (იხ. ბრძანებების კონტროლი). ასეთი სტრიქონები ჩანს ჩანართზე Commands. სია თავად ახლდება, გადატვირთვის გარეშე: New commands appear here as soon as they are held. The page does not need to be reloaded. თუ კავშირი დაიკარგა: The live connection was lost. Reload the page to see what is waiting.

• ჩანართის გახსნისას ვინაობის დადასტურებაზე გადახვალთ, თუ ახალი დადასტურება არ არის. გვერდი აჩვენებს, კიდევ რამდენ ხანს მოქმედებს ის: Your confirmation is valid for another …. როცა ვადა გავიდა: Your confirmation has run out, so Allow is off until you confirm again. ბრძანება არ ელოდება, სანამ დაადასტურებთ, ამიტომ ეს წინასწარ გააკეთეთ.
• ბარათი: Command held for confirmation, Person, სერვერი და ანგარიში, Policy and entry, Confirmations: X of Y, Time left: … s, Command (პაროლები და გასაღებები დაფარულია იქ, სადაც მათი ამოცნობა ხერხდება).
• შეხსენება: You confirm a text, not a program. Aliases, functions and key bindings can make a line do something other than what it says.
• Last screen rows — სეანსის ეკრანის ბოლო სტრიქონები (თუ პოლიტიკაში ჩართულია Show the last screen rows to the confirmer). მათ აწერია From the target: ისინი თავად სერვერმა დაწერა, მას ნებისმიერი გამოტანის გაყალბება შეუძლია, ამიტომ ისინი არაფერს ამტკიცებს.
• Lines read earlier in this session — სეანსის წინა სტრიქონები. სტრიქონები, რომლებიც ბრძანებებს ან კლავიშებს ცვლის (alias, function, bind), მონიშნულია redefines a command or a key.
• ბმული Watch live მხოლოდ იმ ადამიანს აქვს, რომელიც ამავდროულად Auditor-იცაა: სეანსის პირდაპირ ყურება მხოლოდ აუდიტორს შეუძლია.

საკუთარი სეანსის დადასტურება შეუძლებელია: This is your own session. Another person has to decide. თუ დრო ამოიწურა, ბრძანება ავტომატურად უარყოფილია (ვადის ამოწურვა უარია). თუ სტრიქონი მოლოდინის დროს შეიცვალა, დადასტურება ძალადაკარგულია: The held line is not the one you were shown, so it was refused. კარიბჭის გადატვირთვისთანავე გვერდი გადაწყვეტილებებს არ იღებს, სანამ მოლოდინში მყოფი ბრძანებების შემოწმება არ დასრულდება: The decision could not be saved. Try again.

ზარი და შეტყობინებები

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

• Requests waiting for your decision: … — ბმული ჩანართზე Waiting for me.
• Commands waiting for your confirmation: … — ბმული ჩანართზე Commands.
• Your requests that were decided: … — მომთხოვნთან; ბმული My requests-ზე.
• ადმინისტრატორისთვის: Rules that no one can approve now: …, New approvers without a console change: …, Directory roles refused (Administrator wins over Approver): ….

ზარის დანარჩენი პუნქტები აღწერილია განყოფილებებში გადაუდებელი წვდომა, შეტყობინებები და ბრძანებების კონტროლი.

გადაუდებელი წვდომა

გადაუდებელი წვდომა (ინგლისურად break-glass, «მინის გატეხვა») — სერვერზე დამტკიცების გარეშე მოხვედრის გზა, როცა სამუშაო ლოდინს ვერ ითმენს. ის ისეა მოწყობილი, რომ მისი შეუმჩნევლად გამოყენება შეუძლებელი იყოს: ადამიანი ვინაობას ავთენტიფიკატორის აპის ახალი კოდით ადასტურებს, უთითებს მიზეზს, ხოლო ყველა პასუხისმგებელი პირი მაშინვე იღებს შეტყობინებას. ყოველ გამოყენებას მოგვიანებით აუცილებლად ამოწმებს სხვა ადამიანი.

როგორ რთავს ადმინისტრატორი გადაუდებელ წვდომას

გადაუდებელი წვდომა კონფიგურირდება «მოთხოვნით» ტიპის წესში (განყოფილება წვდომის წესები), ორ ველში:

გადაუდებელი წვდომის ჩართვა მხოლოდ მაშინ შეიძლება, როცა შეტყობინება ნამდვილად მიაღწევს ადრესატს: თუ ბოლო დღე-ღამეში არც ერთ არხს (SIEM-ში ექსპორტი, ელფოსტა ან webhook) არაფერი მიუწოდებია, კარიბჭე უარს ამბობს: Cannot be switched on: no alarm channel (SIEM export, e-mail or webhook) has delivered in the last 24 hours. Set one up under System, send a test and try again. ჯერ არხები გვერდზე Notifications მოარგეთ. ჩართული გადაუდებელი წვდომისას ადამიანების, სერვერების ან ანგარიშების წრის გაფართოება ვინაობის ხელახალ დადასტურებას მოითხოვს.

როგორ სარგებლობს ადამიანი გადაუდებელი წვდომით

პირობები: ამ წყვილისთვის «სერვერი — ანგარიში» მონიშნული ხართ, ავთენტიფიკატორის აპი დადასტურებული გაქვთ (TOTP; კონფიგურირდება პროფილში). თუ აპი არ გაქვთ: Emergency access needs a confirmed authenticator app. Set one up in your profile first.

1. გახსენით ფანჯარა. გვერდზე /access/requests, ჩანართში Available to request, დააჭირეთ წითელ ღილაკს Emergency access საჭირო წყვილის სტრიქონში (BURSUcm-ში — ღილაკი Emergency access მოთხოვნის ფანჯარაში).
2. წაიკითხეთ გაფრთხილება. This skips approval. You will be let in to … as … for … minutes. The use is recorded and must be reviewed afterwards. Use it only if the work cannot wait. ქვემოთ ნათქვამია, ვის ეცნობება: The moment you confirm, Approvers, Auditors and Administrators are told in the console, the emergency alarm recipients by e-mail or webhook, and the SIEM export records the event.
3. შეავსეთ ველები. ისინი ქვემოთაა ჩამოთვლილი.
4. დაადასტურეთ. დააჭირეთ Use emergency access-ს. წარმატებისას: Emergency access granted until …. This use will be reviewed. წვდომა მოქმედებს ამ მომენტიდან წესით განსაზღვრული ვადით და არ ხანგრძლივდება.

შეზღუდვები

• არაუმეტეს 2 გამოყენებისა ერთ ადამიანზე 24 საათში (კონსოლში ეს მნიშვნელობა არ იცვლება).
• არაუმეტეს ერთი მოქმედი გადაუდებელი წვდომისა ერთ ადამიანზე და სერვერზე: You already have emergency access to this server account.
• არასწორი კოდები ითვლება. თუ ანგარიში არასწორი კოდების გამო დაიბლოკა, ფორმა გაცნობებთ დაბლოკვისა და მისი დასრულების დროის შესახებ. გარდა ამისა, გადაუდებელი წვდომის ფორმის გაგზავნაზე მოქმედებს ზღვარი — 10 მცდელობა წუთში ერთ ადამიანზე (პასუხი HTTP 429).
• გამოყენება არ უარიყოფა იმის გამო, რომ შეტყობინების არხები დუმს: მოვლენა მაინც იწერება, ხოლო ჟურნალში ინახება, იყო თუ არა არხი ცოცხალი.
• ლიცენზია მოწმდება ისევე, როგორც ჩვეულებრივი მოთხოვნისთვის.

თუ გამოყენება უარყოფილია, ფორმა შეტყობინებით ბრუნდება, ხოლო კოდის ველი სუფთავდება. შესაძლო შეტყობინებები: Emergency access is not available to you for this server account., Emergency access needs a confirmed authenticator app. Set one up in your profile first., Write a reason of at least 20 characters., Enter the six-digit code from your authenticator app., The code is wrong or was already used., You already have emergency access to this server account., The limit of emergency accesses is reached. Contact the administrator.

რას ხედავს ყველა გამოყენების დროს და შემდეგ

• ადამიანი. კონსოლში ყოველ გვერდზე ჩანს ბანერი Emergency access is active until …. This use is recorded and will be reviewed. SSH-სეანსში, რომელიც მხოლოდ გადაუდებელ წვდომას ეყრდნობა, ტერმინალში არის სტრიქონი Emergency access: this use is recorded, the responsible people have been told, and it will be reviewed. დასრულებამდე ის იღებს ისეთივე გაფრთხილებას, როგორც ჩვეულებრივი წვდომისას; BURSUcm-ში ის ასე ჟღერს: Your emergency access to … as … ends at …. It cannot be extended. გადაუდებელი წვდომის გახანგრძლივება შეუძლებელია; მას ღილაკი Extend არ აქვს, არის მხოლოდ Release access.
• დამმტკიცებლები, აუდიტორები და ადმინისტრატორები. ზარში ჩნდება წითელი პუნქტი Emergency access used and not yet reviewed: …; ადმინისტრატორი დამატებით ხედავს Emergency access reviews overdue: ….
• გადაუდებელი წვდომის განგაშის მიმღებები (სია გვერდზე Notifications) იღებენ წერილს Emergency access was used: request #… და webhook-ს.
• SIEM. გამოყენება ექსპორტში ცალკე მოვლენად ხვდება.
• ბრძანებები. სეანსებზე, რომლებიც მხოლოდ გადაუდებელ წვდომას ეყრდნობა, ავტომატურად მოქმედებს ჩაშენებული პოლიტიკა Break-glass audit (built in): კარიბჭე წერს ყოველ სტრიქონს, რომლის წაკითხვაც ხერხდება. მისი შეცვლა ან წაშლა შეუძლებელია. sudo-ს მოთხოვნისას აკრეფილი პაროლები არ ინახება: შეყვანა არ იწერება.

შემოწმება გამოყენების შემდეგ

ყოველი გამოყენება უნდა შემოწმდეს პარამეტრით განსაზღვრულ ვადაში (ნაგულისხმევად 72 საათი; კონსოლში მნიშვნელობის შეცვლა ჯერ შეუძლებელია). შემოწმების უფლება აქვს ჩართულ Approver-ს ან Auditor-ს, რომელიც არ არის ის, ვინც წვდომით ისარგებლა. მხოლოდ ადმინისტრატორს შემოწმება არ შეუძლია.

გვერდი /audit/breakglass (მენიუ Audit → Emergency access) ხელმისაწვდომია როლებისთვის Administrator, Auditor და Approver. სამი ჩანართი:

• Waiting for review — გამოყენებები შემოწმების გარეშე;
• All uses — ყველა გამოყენება (30 თითო გვერდზე);
• Command list — ბრძანებების სტრიქონები, რომლებიც კარიბჭემ არჩეული გამოყენების სეანსებში წაიკითხა.

ცხრილის სვეტები: Person, Server and account, Reason, Ticket, Used, Sessions, Review. შემოწმების მდგომარეობა: Waiting for review (Review due by …), Overdue (Review overdue since …) ან Reviewed (Reviewed by … on …). ბმულები Sessions და Command list მხოლოდ აუდიტორსა და ადმინისტრატორს უჩანს; დამმტკიცებელი ბრძანებების ტექსტს მხოლოდ ამ გვერდზე ხედავს. ცარიელი გვერდი: Emergency access has not been used.

შემოწმების ღილაკი ხსნის ფანჯარას Review this use:

ღილაკი Close the review შემოწმებას ხურავს: Review closed. ხელახლა დახურვა შეუძლებელია (This use has already been reviewed.), საკუთარი გამოყენების შემოწმების დახურვა შეუძლებელია (You cannot review your own use.); მას, ვინც ისარგებლა, გვერდი აცნობებს: Another Approver or an Auditor reviews your use of emergency access; you cannot close the review. შემოწმება ამოწურული ლიცენზიის დროსაც მუშაობს.

შეტყობინებები

გვერდი /system/notifications (მენიუ System → Settings → Notifications) — მხოლოდ ადმინისტრატორისთვის. აქ კონფიგურირდება, როგორ აცნობებს კარიბჭე ადამიანებს მოთხოვნების, გადაწყვეტილებებისა და გადაუდებელი წვდომის შესახებ: ელფოსტით და ხელმოწერილი webhook-ით. არხის მწყობრიდან გამოსვლა მოთხოვნას არასოდეს ბლოკავს: კარიბჭე მიწოდებას იმეორებს და ზარში პუნქტს აჩენს.

ელფოსტის პაროლი და webhook-ის საიდუმლო მხოლოდ ჩასაწერია: შენახვის შემდეგ ისინი აღარ ჩანს. თუ მნიშვნელობა შენახულია, ველის ქვეშ წერია A value is saved. Leave the field empty to keep it; type a new one to replace it.

გვერდის ველები

შემოწმება და მიწოდების მდგომარეობა

• Send a test e-mail აგზავნის სატესტო წერილს თქვენი ანგარიშის მისამართზე (თემა BURSU PAM test message). ტესტი უკვე შენახულ პარამეტრებს იყენებს: Save the settings first: the test uses the saved ones. თუ თქვენს ანგარიშს მისამართი არ აქვს: Your account has no e-mail address. Add one in your profile first.
• Send a test webhook აგზავნის სატესტო შეტყობინებას შენახულ მისამართზე.
• შედეგი: The test message was sent. ან The test message was not sent: … მიზეზით (მიზეზების სია — თავში «გაუმართაობები»). სანამ ლიცენზია პარამეტრების შეცვლის საშუალებას არ იძლევა, ტესტები უარყოფილია.
• ბარათი Delivery არხების E-mail, Webhook და SIEM export მიხედვით აჩვენებს მდგომარეობას და დროს Last delivered (Never, თუ ჯერ არაფერი მიწოდებულა; not set up, თუ არხი კონფიგურირებული არ არის).

რომელი მოვლენები და ვის

ყოველი ადრესატი წერილს თავის ენაზე იღებს (მისი ანგარიშის ენაზე), ხოლო თუ ის მითითებული არ არის — კარიბჭის ნაგულისხმევ ენაზე. წერილში არ არის ღილაკი «დამტკიცება»: ის კონსოლში მიგიყვანთ და გაცნობებთ, რომ გადაწყვეტა მხოლოდ შესვლის შემდეგ შეიძლება.

Webhook იღებს ყოველ მოვლენას JSON-ის სახით ველებით id, event, at; თუ მოვლენა მოთხოვნას ეხება, ემატება request, state, requester, server, account, period და reason (გრძელი მიზეზი იჭრება). HTTP-სათაურები: X-Bursu-Timestamp (დრო Unix-ის წამებში) და X-Bursu-Signature: v1=…, სადაც მნიშვნელობა არის HMAC-SHA256 სტრიქონიდან «დრო, წერტილი, სხეული» თქვენი საიდუმლოთი. მიმღებმა მხარემ უნდა შეამოწმოს ხელმოწერა და უარყოს ძველი შეტყობინებები. User-Agent — BURSU-PAM-webhook/1.

მიწოდება. შეტყობინებები მუდმივ რიგში ინახება და შეფერხებისას ხელახლა იგზავნება: 20-მდე მცდელობა პაუზებით 1 წამიდან 5 წუთამდე. საფოსტო სერვერის ლოდინი — 60 წამი, webhook-ის — 10.

ზარი

ამ განყოფილებასთან დაკავშირებული პუნქტები: Notifications are failing: … (არხი არ აწვდის), No push channel (SIEM, e-mail, webhook) has delivered in the last 24 hours, so an alarm could go unheard. (განგაში შეიძლება ვერავინ გაიგოს), Emergency access used and not yet reviewed: …, Emergency access reviews overdue: …. ჩვეულებრივი გზა: გახსენით გვერდი Notifications, ნახეთ ბარათი Delivery, გააგზავნეთ ტესტი.

ბრძანებების კონტროლი

ბრძანებების კონტროლი — ეს არის დამცავი ბარიერი და ჟურნალი ადამიანებისთვის, რომლებიც სერვერებზე კარიბჭის გავლით მუშაობენ. კარიბჭე კითხულობს სტრიქონებს, რომლებსაც ადამიანი ტერმინალში შეიყვანს, და წესების (პოლიტიკების) მიხედვით უშვებს, მონიშნავს, მეორე პირის დადასტურებამდე აჩერებს, უარყოფს სტრიქონს ან ხურავს სეანსს.

სად რა მუშაობს

სანამ პოლიტიკა მოქმედებს, სერვერზე გადაიცემა მხოლოდ გარემოს ცვლადები LANG, LC_* და TZ; დანარჩენი უკუიგდება. გარსი ტერმინალის გარეშე (ssh -T) უარყოფილია: წასაკითხი არაფერია. გამონაკლისია სეანსი, რომელიც მხოლოდ გადაუდებელ წვდომას ეყრდნობა: იქ მუშაობს მხოლოდ ჩაშენებული პოლიტიკა Break-glass audit (built in), და ტერმინალი სავალდებულო არ არის.

გვერდი «Command control»

მისამართი /commands, მენიუ Access → Command control. გვერდს ხედავენ Administrator და Auditor; აუდიტორი მხოლოდ კითხულობს, ადმინისტრატორი ცვლის. ზემოთ — განმარტება, ბმული What command control cannot stop და მთვლელი Commands waiting for confirmation: …. ოთხი ჩანართი: Policies, Pattern groups, Tester, Starter packs.

როგორ არის მოწყობილი: შაბლონების ჯგუფები და პოლიტიკები

1. შაბლონების ჯგუფი (Pattern group) პასუხობს კითხვას «რა ვეძებოთ»: შაბლონების ნაკრები, მაგალითად წაშლის ბრძანების ყველა ვარიანტი.
2. პოლიტიკა (Policy) პასუხობს კითხვას «რა გავაკეთოთ»: ვის და რომელ სერვერებს ეხება ის და რა თანმიმდევრობითაა ჩამოთვლილი მისი ჩანაწერები (ჩანაწერი = შაბლონების ჯგუფი + მოქმედება). წყვეტს პირველი შესაბამისი ჩანაწერი.
3. ერთ ადამიანზე ერთ სერვერზე შეიძლება რამდენიმე პოლიტიკა მოქმედებდეს. თითოეული ცალკე აფასებს, იმარჯვებს ყველაზე მკაცრი შედეგი. მოგვიანებით დამატებულ პოლიტიკას მხოლოდ გამკაცრება შეუძლია.

შაბლონების ჯგუფები

ჩანართი Pattern groups: სვეტები Group, Patterns, Syntax, Used by; ღილაკი New group. ცარიელი სია: No pattern groups yet.

ბმული Try it in the tester ხსნის შემოწმებას. ჯგუფის, რომელსაც პოლიტიკა იყენებს, წაშლა შეუძლებელია (A policy uses this group. Take it out of the policy first.).

პოლიტიკები

მისამართები: /commands/policies/new (შექმნა), /commands/policies/{ნომერი} (ბარათი), /commands/policies/{ნომერი}/edit (რედაქტირება). ბარათში — Edit, ჩართვის გადამრთველი (Enable / Disable), Delete და ბლოკი What this affects now (რომელი სერვერები და ადამიანები ხვდება ახლა პოლიტიკის ქვეშ). ჩაშენებული პოლიტიკის Break-glass audit (built in) შეცვლა, გამორთვა ან წაშლა შეუძლებელია.

ჩანაწერის მოქმედებები:

პოლიტიკის გამორთვისას კარიბჭე კითხულობს Switch this policy off? The commands it checks run unchecked from the next moment., წაშლისას — Delete this policy? Its past events stay in the audit log.

სტრიქონის შემოწმება

ჩანართი Tester (Try a command line) აჩვენებს, როგორ წაიკითხავს კარიბჭე სტრიქონს. არაფერი ეშვება და არც ერთ სეანსს არ ეხება: Nothing is run and no session is touched.

ღილაკი Check the line აჩვენებს: Words (სიტყვები), Simple commands (მარტივი ბრძანებები), Without wrappers (sudo, env, nice and the like), Matching entry, Result. შესაძლო შედეგები: No entry matches., Nothing matched, so the line would run., Nothing matched, and an allow-list policy refuses what it does not list., The gateway cannot see what this line runs: …, The line is unfinished (…), This line cannot be shown safely to a confirmer, so it could not be confirmed. ლიმიტი — 30 შემოწმება წუთში ერთ ადამიანზე, თორემ Too many checks in a minute. Wait a moment.

მზა ნაკრებები

ჩანართი Starter packs შეიცავს 19 ნამზადს, დაჯგუფებულს ოჯახების მიხედვით: Linux (6), Cisco (3), Huawei (3), MikroTik (3), ერთჯერადი ბრძანებები (1) და მონაცემთა ბაზები (3). თითოეული მიუთითებს, რას ეყრდნობა (Relies on …). ღილაკი Make a policy პოლიტიკას გამორთულს ქმნის: Policy … was created disabled. Review it before you switch it on. შეამოწმეთ ჩანაწერები, მიუთითეთ მოქმედების არე და ჩართეთ. Allow-list ნაკრები ინტერაქტიული გარსებისთვის არ არსებობს: ის არღვევს მოსაწვევებს და პროგრამებს.

რას ხედავს მომხმარებელი ტერმინალში

კარიბჭე წერს უბრალო ტექსტით ცალკე სტრიქონში, პრეფიქსის გარეშე, კარიბჭის ნაგულისხმევ ენაზე (SSH-სეანსს საკუთარი ენა არ აქვს).

დაჭერილი და შეჩერებული Enter სეანსის ვადის ამოწურვას არ იწვევს: სანამ შემოწმება მიმდინარეობს, სეანსი აქტიურად ითვლება. შეჩერების დროს აკრეფილი კლავიშები რიგში დგება (4 კიბ-მდე) და გადაწყვეტილების შემდეგ თანმიმდევრობით მოწმდება; თუ სტრიქონი უარყვეს, რიგი სუფთავდება.

მეორე პირის დადასტურება

დადასტურების ლოდინი მოგიწევთ არაუმეტეს მნიშვნელობისა Wait for a command confirmation, seconds (ნაგულისხმევად 120 წამი; მითითება გვერდზე Notifications). ვადის ამოწურვა უარს ნიშნავს. დამადასტურებელი ბრძანებას ხედავს ჩანართზე Commands გვერდზე Approvals, იხ. ბრძანებების დადასტურება. თუ არც ერთი შესაფერისი დამადასტურებელი არ არის, ბრძანება მაშინვე უარყოფილია: No second person is available to confirm this command, so it was not run. ერთდროულად დადასტურებას შეიძლება ელოდებოდეს არაუმეტეს ერთი ბრძანებისა სეანსიდან, სამი ბრძანებისა ერთი ადამიანისგან და ორმოცდაათისა მთელ კარიბჭეზე; ამაზე მეტისას სტრიქონი არ სრულდება და კარიბჭე წერს Too many commands are waiting for confirmation on this gateway; this one was not run. Try again shortly.

ბრძანებების კონტროლი და კლიენტები

BURSUcm (Windows და Universal) ბრძანებების კონტროლის მქონე სერვერზე ამ კავშირისთვის თავის tmux-ს გამორთავს და გარსში ინტეგრაციის სტრიქონებს არ აგზავნის. ამის გამო არ მუშაობს «Files» პანელის გადასვლა გარსის კატალოგის კვალდაკვალ და ბრძანებების ნიშნები ხელოვნური ინტელექტის ასისტენტთან. ტერმინალის ჩანართზე ჩნდება ნიშანი Command control is on მინიშნებით: Command control is on: the gateway checks the commands typed on this server, and tmux is off for this connection. This app types nothing into the shell here, so Files does not follow the shell's folder and the AI assistant has no command marks.

რას ვერ ხედავს კონტროლი

• ინტერპრეტატორები: python -c, perl -e, awk, vi :! ასრულებენ ბრძანებებს, რომლებსაც სტრიქონი არ აჩვენებს.
• პროგრამები გარსში გასვლით: less, man, find -exec, git.
• ფსევდონიმები და ფუნქციები, რომლებიც ადრე განისაზღვრა სეანსში ან გარსის გაშვების ფაილში.
• ხერხები ცვლადებითა და ბრჭყალებით (ბრძანება $x-ში), ისტორიის გაშლა (!!), SFTP-ით ატვირთული და გაშვებული სკრიპტი.
• ssh შემდგომ სამიზნე სერვერიდან სხვაზე; stty -echo და კლავიშების გადანიშვნა (bind, bindkey, zle): კარიბჭე ხშირ შემთხვევებს ამჩნევს, მაგრამ არა ყველას.
• პროგრამები, რომლებიც ბრძანებებს საკუთარი შეყვანიდან კითხულობენ (psql, mysql, sqlite3, gdb, expect, vim -es), და შეყვანა სრულეკრანიან პროგრამებში, რედაქტორებსა და პაროლის მოთხოვნებში. ასეთი სტრიქონები «წაუკითხავად» ითვლება და აღირიცხება.

რას წერს კარიბჭე: წაკითხული სტრიქონი, რომელიც პოლიტიკას დაემთხვა (ან ნებისმიერი სტრიქონი, თუ ყველას ჩაწერა ჩართულია), ხვდება სეანსის ბრძანებების სიაში პაროლებისა და გასაღებების დაფარვით (დაფარვა გარანტირებული არ არის) და ჩანაწერთან ერთად იშლება. აუდიტის ჟურნალი ბრძანების ტექსტს არ შეიცავს — მხოლოდ ანაბეჭდს, პოლიტიკასა და შედეგს. ბრძანებების ტექსტს კითხულობენ Auditor და Administrator; Approver — მხოლოდ იმას, რაც მას დასადასტურებლად გაეგზავნა, და გადაუდებელი წვდომის შემოწმებებს.

როლი «Approver»

როლი Approver («დამმტკიცებელი») ადამიანს ენიჭება განყოფილებაში Users (ან მოდის დირექტორიის ჯგუფიდან). დამმტკიცებელი კარიბჭეს არ აკონფიგურირებს, არამედ იღებს გადაწყვეტილებებს: წვდომის მოთხოვნებზე, შეჩერებულ ბრძანებებზე და გადაუდებელი წვდომის შემოწმებებზე. როლი თავისთავად სერვერებზე წვდომას არ იძლევა.

შეუთავსებლობა ადმინისტრატორთან

ერთი და იგივე ადამიანი არ შეიძლება ერთდროულად იყოს Administrator და Approver: არ შეიძლება წვდომის დამტკიცება და ამავდროულად იმ წესების წერა, რომლითაც ის გაიცემა. მინიჭებისას ფორმა გამოიტანს Approver and Administrator exclude each other: nobody approves requests while managing the rules. Choose one of the two. და, შენახვისას, A person cannot be both an Administrator and an Approver. თუ ადამიანი ორივე როლს დირექტორიის ჯგუფებიდან იღებს, იმარჯვებს Administrator, როლი Approver უარყოფილია და გაფრთხილებებში გამოჩნდება (Directory roles refused (Administrator wins over Approver): …).

ადმინისტრატორს, რომელსაც დამტკიცება სჭირდება, ცალკე ანგარიში სჭირდება როლით Approver.

რას ხედავს და რა შეუძლია დამმტკიცებელს

რას ვერ ხედავს დამმტკიცებელი: კონფიგურაციის გვერდებს (სერვერები, ანგარიშები, წესები, მომხმარებლები, სისტემა), აუდიტის ჟურნალს, სეანსების ჩანაწერებს, ბრძანებებს დადასტურების გარეთ. სხვის მოთხოვნებს, რომლებზეც დაშვებული არ არის, ის საერთოდ ვერ ხედავს.

დამმტკიცებლის სამუშაო დღე

1. შედით კონსოლში. მენიუში Access არის პუნქტი Approvals ნიშანზე მომლოდინე მოთხოვნების რიცხვით. ზარი შეგახსენებთ მოთხოვნებსა და დადასტურების მომლოდინე ბრძანებებს.
2. დაადასტურეთ ვინაობა. დაშვებისთვის (მოთხოვნის ან ბრძანების დამტკიცებისთვის) საჭიროა დადასტურება, ის 10 წუთი მოქმედებს. დაადასტურეთ წინასწარ, განსაკუთრებით თუ ბრძანებებზე მორიგეობთ: მომლოდინე ბრძანება თქვენთვის არ შეჩერდება.
3. დაამუშავეთ «Waiting for me». ყოველი მოთხოვნისთვის წაიკითხეთ მიზეზი, ტიკეტის ნომერი, ვადა და ნახეთ, რას ითხოვდა და აკეთებდა ადამიანი ამ სერვერზე ადრე. დაამტკიცეთ, საჭიროების შემთხვევაში უფრო მოკლე ვადით, ან უარყავით კომენტარით.
4. თვალი ადევნეთ ჩანართს «Commands», თუ პოლიტიკის დამადასტურებელი ხართ. გადაწყვიტეთ ბარათზე დაყრდნობით; გახსოვდეთ, რომ ადასტურებთ ტექსტს და არა პროგრამას.
5. შეამოწმეთ «Active grants», თუ წვდომის ვადამდე გაუქმებაა საჭირო (ადამიანმა სამუშაო დაასრულა, ეჭვები, შეცდომა მოთხოვნაში).
6. შეამოწმეთ გადაუდებელი წვდომის გამოყენებები გვერდზე Emergency access და დახურეთ შემოწმება დასკვნითა და შენიშვნით. საკუთარ გამოყენებებს ვერ დახურავთ.

მიმოხილვა: კარიბჭის მდგომარეობა

გვერდი Overview (მისამართი /overview) — პირველი, რასაც ადმინისტრატორი და აუდიტორი შესვლის შემდეგ ხედავენ. ის ორ კითხვას პასუხობს: «ყველაფერი რიგზეა თუ არა კარიბჭესთან» და «რა ხდებოდა ბოლო დროს». გვერდი არაფერს ცვლის, მხოლოდ აჩვენებს. მას ხედავენ როლები Administrator და Auditor; მომხმარებლისთვის, რომელსაც მხოლოდ როლი User აქვს, და დამმტკიცებლისთვის (Approver) ეს გვერდი მიუწვდომელია.

გვერდის ყველა წაკითხვას ერთად არაუმეტეს ხუთი წამი ეთმობა, თითოეული მნიშვნელობა კი ცალკე იკითხება. თუ რომელიმე მნიშვნელობის წაკითხვა ვერ მოხერხდა ან დროულად ვერ მოესწრო (მაგალითად, მონაცემთა ბაზამ არ უპასუხა), რიცხვის ნაცვლად დგას ტირე «—» ან სიტყვა unknown, დანარჩენი გვერდი კი ჩვეულებრივ მუშაობს. ტირე კარიბჭის შეცდომა კი არ არის, არამედ შეტყობინება «ვერ გაირკვა»; ერთ წუთში განაახლეთ გვერდი.

ბლოკი «Where to start»

ბლოკი მხოლოდ ადმინისტრატორს უჩანს და მხოლოდ მანამ, სანამ ერთი ნაბიჯი მაინც შესრულებული არ არის. ის ჩამოთვლის ოთხ ნაბიჯს პირველ დაკავშირებამდე: Add a server, Add a server account, Create a user, Create an access rule. შესრულებული ნაბიჯი თავისით აღინიშნება ნიშნულით; შეუსრულებელს აქვს ღილაკი Open, რომელიც შექმნის გვერდზე გადადის. მრიცხველი მარჯვნივ აჩვენებს «{შესრულებულთა რაოდენობა} of 4». როცა ოთხივე ნაბიჯი შესრულებულია, ბლოკი ქრება. ნაბიჯი «მომხმარებლის შექმნა» შესრულებულად მხოლოდ მაშინ ითვლება, როცა არსებობს ჩართული მომხმარებელი როლით User: ადმინისტრატორი, აუდიტორი და გამორთული ანგარიშები არ ითვლება.

ბარათები რიცხვებით

შესვლების გრაფიკი და ბოლო მოვლენები

გრაფიკი Console sign-ins («Successful sign-ins and refusals per day») დღეების მიხედვით აჩვენებს ვებ-კონსოლში წარმატებული შესვლების (Successful) და უარების (Refused) რაოდენობას. გადამრთველი Period — Week (7 დღე, ნაგულისხმევად) ან Month (30 დღე). დღეები ითვლება ჩვენების სასაათო სარტყლით, რომელიც gateway.json-შია მითითებული (displayTimeZone, იხ. gateway.json).

ბლოკი Latest events — აუდიტის ჟურნალის ათი ბოლო მოვლენა. მოვლენის სათაური მისი ბარათის ბმულია. ღილაკი Audit log სრულ ჟურნალს ხსნის.

ბლოკი Health: რას ნიშნავს თითოეული ინდიკატორი

ბლოკი Health («Checked when the page opens (at most every 30 s)») კარიბჭის თვითშემოწმებაა. მდგომარეობა იკითხება გვერდის გახსნისას და არა უმეტეს 30 წამში ერთხელ, ამიტომ გაუმართაობის გამოსწორების შემდეგ ინდიკატორი შეიძლება მაშინვე არ გამწვანდეს. თითოეულ ინდიკატორს მარჯვნივ მდგომარეობის სიტყვა აქვს: fine (მწვანე, რიგზეა), attention (ყვითელი, ყურადღებაა საჭირო), problem (წითელი, მოქმედებაა საჭირო), off (ნაცრისფერი, ფუნქცია გამორთულია). სიტყვა იმ გვერდის ბმულია, სადაც გაუმართაობა სწორდება, თუ მისი გახსნის უფლება გაქვთ. აუდიტორი ინდიკატორებს ხედავს, მაგრამ პარამეტრების გვერდების ბმულები მისთვის არ მუშაობს (პარამეტრები მხოლოდ ადმინისტრატორისთვისაა ხელმისაწვდომი).

ყოველთვის ჩანს ექვსი ინდიკატორი:

დანარჩენი ინდიკატორები მხოლოდ მაშინ ჩნდება, როცა შესაბამისი ფუნქცია მორგებულია:

ზარი «Alerts»

ყოველი გვერდის ზედა პანელში არის ზარი Alerts. მასში მხოლოდ მიმდინარე პრობლემებია თავმოყრილი: Health ბლოკის ყველა ყვითელი და წითელი ინდიკატორი და კიდევ რამდენიმე შეტყობინება, რომლებიც Health ბლოკში არ არის. თუ პრობლემები არ არის, წერია No current problems. შეტყობინებებს ხედავს როგორც ადმინისტრატორი, ისე აუდიტორი; გამოსწორების გვერდის ბმულს მხოლოდ ის იღებს, ვისაც მისი გახსნის უფლება აქვს.

სეანსები: სიები, ყურება, დასრულება

განყოფილება Sessions (გვერდითი მენიუს ჯგუფი Audit) პასუხობს კითხვებს «ვინ მუშაობს ახლა სერვერებზე» და «ვინ და როდის მუშაობდა ადრე». განყოფილების გვერდებს ხედავენ Administrator და Auditor. დამმტკიცებელი (Approver) და ჩვეულებრივი მომხმარებელი მათ ვერ ხსნიან. აუდიტორს შეუძლია ნახოს, მოძებნოს, დაუკრას ჩანაწერები და დაასრულოს სეანსები, მაგრამ არაფერს აწყობს (თავი «აუდიტორის როლი»).

როგორ არის მოწყობილი განყოფილება

გვერდით მენიუში განყოფილებას ერთი პუნქტი აქვს — Sessions — ყველა პროტოკოლისთვის. SSH-ის, RDP-ის, VNC-ის და მონაცემთა ბაზებისთვის ცალკე პუნქტები არ არის. განყოფილების ყველა გვერდზე სათაური ერთი და იგივეა — Sessions, მის ქვეშ კი ხუთი ჩანართის ზოლია: