წარმოიდგინეთ ასეთი სიტუაცია: ერთ VPS-ზე გაქვთ ხუთი საიტი. ერთ ძველ WordPress plugin-ში აღმოჩნდა სისუსტე და თავდამსხმელმა ფაილის ატვირთვა შეძლო. ახლა მთავარი კითხვა აღარ არის „VPS რამდენად ძლიერია?“. მთავარი კითხვაა - იმ ერთი საიტიდან რამდენად შორს შეუძლია თავდამსხმელს წასვლა?
სწორად აწყობილ გარემოში პასუხი უნდა იყოს: რაც შეიძლება ცოტა. ცუდად აწყობილში კი ერთი საიტის პრობლემა შეიძლება ყველა დანარჩენის პრობლემად გადაიქცეს.
თუ ამ თემას shared გარემოსთან ადარებთ, საზიარო ჰოსტინგის უსაფრთხოების მიმოხილვა დაგეხმარებათ გაიგოთ, რატომ არის isolation სხვადასხვა hosting model-ში განსხვავებული.
რა ხდება, როცა ხუთივე საიტი ერთ user-ზეა
თუ ყველა პროექტს ერთი system user, ერთი ფართო file permission და ერთმანეთზე გადაჯაჭვული credentials აქვს, იზოლაცია ფაქტობრივად არ არსებობს. კომპრომეტირებულმა პროცესმა შესაძლოა მეზობელი საიტების configuration files წაიკითხოს, database credentials ნახოს ან მათი ფაილებიც შეცვალოს.
ეს არ ნიშნავს, რომ „ერთ VPS-ზე ბევრი საიტი ცუდია“. პრობლემა არქიტექტურაშია და არა თვითონ VPS-ში.
იზოლაცია ფენებად ააწყვეთ
- ცალკე users/subscriptions. თითოეული საიტი საკუთარი უფლებებით უნდა მუშაობდეს.
- მინიმალური file permissions. web process-ს არ უნდა ჰქონდეს წვდომა იქ, სადაც სამუშაოდ არ სჭირდება.
- ცალკე database credentials. ერთი საიტის database user-ს სხვა ბაზების კითხვა არ უნდა შეეძლოს.
- process separation. PHP/process pool-ები ისე მოაწყვეთ, რომ ერთი პროექტის ქცევა დანარჩენებს ნაკლებად შეეხოს.
- backup-ის დამოუკიდებელი ასლი. თუ attacker იმავე სერვერზე backup-საც შლის, ის recovery plan აღარ არის.
WordPress გარემოში isolation-სთან ერთად malware detection-იც მნიშვნელოვანია; ამისთვის ნახეთ Imunify360-ისა და malware დაცვის მიმოხილვა.
საფრთხის ოთხი წითელი დროშა
- ყველა კლიენტის საიტზე ერთი ადმინისტრაციული პაროლი გამოიყენება;
- ყველა საიტი ერთი system account-ის ქვეშაა;
- CMS/plugin განახლებები თვეებით იგვიანებს;
- backup მხოლოდ იმავე VPS-ის დისკზე ინახება.
თუ აქედან ორზე მაინც პასუხი „კი“ არის, პირველ რიგში ინფრასტრუქტურის დალაგებას მივხედავდი და მხოლოდ მერე - მეტი CPU/RAM-ის ყიდვას. ზოგადი server-hardening თემისთვის შეგიძლიათ ნახოთ სერვერის უსაფრთხოების სტატიაც.
თუ ეს რამდენიმე საიტი სხვადასხვა კლიენტს ეკუთვნის და root-level მოქნილობა საერთოდ არ გჭირდებათ, Reseller Hosting ხშირად უფრო ბუნებრივი მოდელია: კლიენტების ცალკე ანგარიშები და Plesk-იდან ცენტრალიზებული მართვა.
როდის აღარ ღირს ყველაფრის ერთ VPS-ზე დატოვება
ზოგჯერ კარგი იზოლაციაც არ არის საკმარისი მიზეზი საერთო გარემოს შესანარჩუნებლად. მაგალითად, თუ ერთ საიტს დიდი traffic აქვს, მეორე კლიენტს მკაცრი უსაფრთხოების მოთხოვნები, ხოლო მესამე მაღაზია შემოსავლის კრიტიკული წყაროა, მათი ცალკე VPS-ებზე გაყოფა შეიძლება უფრო სწორი საოპერაციო გადაწყვეტილება იყოს.
ასევე გაითვალისწინეთ რესურსის რისკი: ერთი ცუდად დაწერილი cron job ან traffic spike შესაძლოა CPU/RAM-ზე ყველას შეეხოს. ამ შემთხვევაში monitoring და resource limits ისეთივე მნიშვნელოვანია, როგორც permissions.
ერთი VPS-ზე რამდენიმე საიტის უსაფრთხოდ გაშვება შესაძლებელია. მაგრამ „ერთ სერვერზე არიან“ არ უნდა ნიშნავდეს „ერთ უსაფრთხოების საზღვარში არიან“.
თუ ამ ტიპის გარემოს აწყობთ, Managed VPS შეიძლება გამოგადგეთ სისტემური მხარის სამართავად, ხოლო აპლიკაციების იზოლაცია და კოდის უსაფრთხოება მაინც ცალკე, გააზრებულ პროცესად უნდა დარჩეს.
