Сервери, які тримаються самі

1. Google Cloud

   Інстанси Compute Engine, Cloud SQL там, де керована база виправдовує свою ціну, Cloud Storage для медіа та бекапів, балансувальник попереду, коли вузлів більше одного. Снапшоти за розкладом, розміри інстансів переглядаються за реальним трафіком, а не вгадуються на старті.

2. Amazon Web Services

   EC2 з томами EBS та політиками снапшотів, S3 для статики та копій поза майданчиком, RDS — коли базу краще не тримати самостійно, Route 53 і CloudFront для DNS та доставки. Security groups пишуться як список із забороною за замовчуванням, а не відкриваються по ходу справи.

3. Звичайний VPS

   Для більшості сайтів це чесна відповідь. Одна грамотно налаштована машина в європейського провайдера тягне навантажену інсталяцію WordPress або Shop-Script швидше й набагато дешевше, ніж хмарна архітектура, яку в команді ніхто не вміє лагодити.

4. Власне залізо

   У вашому офісі або в дата-центрі. RAID із перевіреним перезбиранням, позасмуговий доступ, щоб перезавантаження не вимагало їхати на місце, ДБЖ, задокументований запасний комплект і другий канал там, де бізнес не може перечекати аварію провайдера.

1. Debian та Ubuntu Server

   LTS-релізи, на пакетах вендора, а не на купі сторонніх репозиторіїв. Автоматичні оновлення безпеки, SSH за ключем із вимкненим входом під root, fail2ban, nftables або ufw закриті за замовчуванням, journald і logrotate налаштовані так, щоб про розрослий лог ви дізнавалися не по забитому диску.

2. Windows Server 2012 і новіші

   Аж до актуальних релізів: IIS з окремим пулом застосунків на сайт, MS SQL Server, Active Directory та групові політики, служби віддалених робочих столів, файлові шари з квотами й тіньовими копіями. Оновлення ставляться за графіком, а не відкладаються, і шлях міграції планується до того, як версія вийде з підтримки.

3. Контейнери там, де вони допомагають

   Docker і Compose — щоб зафіксувати стек, який має збігатися між staging і продакшеном, або щоб тримати поруч кілька версій PHP чи Node. Не для того, щоб ускладнити сервер з одним сайтом понад потрібне.

1. nginx або nginx перед Apache

   лише nginx, де це дозволяє застосунок; як зворотний проксі-сервер перед Apache, де правила .htaccess повинні продовжувати працювати. HTTP/2, gzip та Brotli, обмеження для клієнтів sane та статичні файли, що обслуговуються без будь-якого пробудження PHP.

2. PHP-FPM, по пулу на сайт і в ізоляції

   Окремий пул та окремий системний користувач на кожен сайт, щоб скомпрометований плагін не зміг прочитати сусіда. OPcache під розмір кодової бази, збільшений realpath cache, ліміти виставлені за замірами, версія обирається для кожного сайту, а не для всієї машини.

3. MySQL, MariaDB або PostgreSQL

   Буферний пул підібраний під реальний обсяг даних, лог повільних запитів увімкнено та прочитано, індекси додаються там, де на це вказує лог. Дампи знімаються узгоджено, а на великих обсягах зберігаються бінарні логи, щоб відновлюватися на точку в часі, а не на минулу ніч.

4. Redis або Memcached

   Об'єктний кеш і сесії — поза базою та поза файловою системою, зі свідомо заданою політикою витіснення та стелею пам'яті. Слухає localhost або приватну мережу: відкритий назовні Redis — одна з найнадійніше експлуатованих речей в інтернеті.

5. Node.js, коли його вимагає фронтенд

   Збірка виконується в пайплайні, а не на бойовому сервері. Довгоживучі процеси — під systemd, з політикою перезапуску та збиранням логів, а не в сесії screen, яку хтось колись відкрив.

6. TLS, який поновлюється сам

   Let's Encrypt через ACME з автопродовженням і хуком, який перезавантажує вебсервер, або комерційний сертифікат — встановлений і поставлений на контроль. Сучасні набори шифрів, HSTS там, де на нього безпечно підписатися, і термін дії під наглядом ззовні машини.

1. Домен та групові політики

   Active Directory з другим контролером, щоб одна відмова не залишила офіс без входу в систему. Політики підключення дисків, принтерів, блокування екрана та встановлення ПЗ застосовуються централізовано, а не на кожній машині окремо.

2. Файловий сервер

   Шари з правами за оргструктурою, квоти, щоб один відділ не забив увесь том, і тіньові копії, щоб перезаписаний документ був проблемою на дві хвилини, а не заявкою на відновлення.

3. Термінальний сервер

   Служби віддалених робочих столів для бухгалтерії та профільних застосунків: ліцензовані коректно, розраховані на реальну кількість одночасно працюючих і доступні з дому через VPN, а не виставлені в інтернет.

4. Віддалений доступ

   WireGuard або OpenVPN в офісну мережу, персональні ключі, які відкликаються, коли співробітник іде. Відкритий назовні RDP — це те, як заходить шифрувальник, і він досі найчастіше й виявляється в успадкованій мережі.

5. Пошта, яка доходить

   SPF, DKIM і DMARC налаштовані коректно під вашого провайдера, плюс зворотний DNS там, де пошта йде зі свого сервера. За більшістю звернень «наші рахунки йдуть у спам» стоїть один відсутній DNS-запис.

1. Закрито за замовчуванням

   Фаєрвол забороняє все й відкривається порт за портом під названу причину. Бази, кеші та адмін-інтерфейси слухають localhost або приватну мережу — і ніколи публічну адресу просто тому, що так було простіше при налаштуванні.

2. Доступ, який можна відкликати

   Іменні облікові записи замість одного спільного логіна, SSH-ключі замість паролів, sudo замість root, двофакторка скрізь, де панель її підтримує. Коли людина йде, одне відкликання закриває їй доступ усюди — але лише якщо так було побудовано від початку.

3. Сайти ізольовані один від одного

   Один системний користувач та один пул PHP на сайт. На спільному сервері заходять зазвичай не через захищений сайт, а через забутий сусідній — і ізоляція якраз не дає цьому стати спільною проблемою.

4. Оновлення, які справді встановлюються

   Автоматичні оновлення безпеки на Linux, заплановане вікно оновлень на Windows та відстеження дат завершення підтримки, щоб версія тихо не перестала отримувати виправлення, продовжуючи при цьому тримати ваш бізнес.

5. Перебір паролів і шкідливий трафік

   fail2ban на SSH і на формах входу, ліміти частоти на вебсервері, Cloudflare або аналог попереду там, де це виправдано обсягом. Сторінки входу атакують постійно; питання лише в тому, чи рахує це хтось.

6. Секрети поза кодом

   Паролі до баз та API-ключі — у конфігурації оточення з жорсткими правами, не в репозиторії та не у файлі, який вебсервер із радістю віддасть назовні. Змінюються, коли йде будь-хто, у кого був доступ.

7. План на день, коли це станеться

   Якщо сайт скомпрометовано: ізолювати, зберегти сліди, перезібрати з завідомо чистого джерела, а не видаляти ті файли, що трапилися на очі, змінити всі доступи й лише потім знайти точку входу. Чистка без знайденої точки входу означає повторення через два тижні.

Найчастіша знахідка в успадкованій мережі — не екзотика: це відкритий в інтернет RDP або той самий пароль на сервері, у панелі та в базі. І те й інше лагодиться за півдня, і це два основні шляхи, якими зазвичай приходить шифрувальник.

1. Три копії, два типи носіїв, одна поза майданчиком

   Старе правило, і воно й досі головне. Копія на тому самому сервері — не бекап: вона згорить разом із машиною і буде видалена тим самим, що видалило оригінал.

2. Файли, база даних та конфігурація

   Усі три, інакше відновлення перетворюється на головоломку. База без завантажених файлів — це половина сайту; і те й інше без конфігурації вебсервера та cron — це день відновлення по пам'яті.

3. Копії, до яких не дістанеться шифрувальник

   Сховище поза майданчиком із версіонуванням або режимом append-only, і доступи, які не лежать на тому самому сервері, що бекапиться. Сучасний шифрувальник насамперед шукає резервні копії — і знаходить їх, якщо сервер може їх видалити.

4. Глибина зберігання, якої вистачить

   Щоденні копії зберігаються два тижні, щотижневі — пару місяців, щомісячні — довше. Пошкодження даних і тиху втрату помічають через тижні, і одна перезаписана копія на той момент уже нічим не допоможе.

5. Відновлення на точку в часі

   Там, де це виправдано цінністю даних, — бінарні логи або снапшоти, щоб повернутися на годину назад, а не на минулу ніч. Це різниця між втратою замовлень за півдня та відсутністю втрат.

6. Відновлення, які справді перевірені

   Кожен набір копій розгортається на тестовому стенді із заміром часу — так стає відомо і що він робочий, і скільки триває відновлення. Планують саме за цією цифрою, і майже ні в кого її немає.

Обрізані дампи, відсутні завантажені файли, завдання, яке зупинилося місяці тому й нікому про це не сказало, — це звичайні відмови, і кожна з них невидима рівно до моменту, коли бекап знадобився. Лише перевірка перетворює резервну копію з надії на факт.

1. Деплой

   Код потрапляє на сервер завжди одним і тим самим шляхом — із репозиторію, через пайплайн, зі збіркою та з можливістю відкотитися. Ніхто не править бойовий файл по FTP, бо саме так сайти й ламаються об одинадцятій вечора.

2. Бекапи, які розгорталися

   Файли й база — поза сервером, за розкладом, із глибиною зберігання. І далі те, що пропускають у більшості налаштувань: реальне відновлення, виконане та заміряне за часом, бо бекап, який ніхто не розгортав, — це надія, а не бекап.

3. Моніторинг та сповіщення

   Доступність, термін дії сертифіката, диск, пам'ять, навантаження, глибина черги та частка помилок — під наглядом ззовні сервера та з доставкою тому, хто може відреагувати. Сповіщення, яке ні до кого не доходить, — це не моніторинг.

4. Staging, ідентичний продакшену

   Друге оточення на тому самому стеку й тих самих версіях, із даними, на яких безпечно працювати. Більшість сюрпризів у день запуску — це відмінності між двома оточеннями, про які ніхто не знав.

5. Міграції без простою

   Зміна хостингу, версії PHP або бази даних — із запланованим перемиканням, а не зі спробою: репетиція на копії, заздалегідь знижений TTL, перемикання в тиху годину, старе оточення залишається, поки нове не доведе свою працездатність.

6. Адміністрування

   Оновлення, керування користувачами та доступами, розбір логів, перевірка запасу за ресурсами та заздалегідь описаний порядок дій при аварії. Невдячна половина роботи — і причина, з якої друга половина продовжує працювати.

1. Аудит

   Що працює, на чому, до якої версії оновлено, як резервується та в кого є доступ. На виході — письмовий список знахідок, відсортований за тим, що вдарить найсильніше, незалежно від того, чи буде продовження.

2. Стабілізація

   Знахідки, небезпечні просто зараз: сервіси, що стирчать назовні, відсутні або неперевірені бекапи, сертифікати, що спливають, неоновлені версії. Лагодяться першими, до будь-яких покращень.

3. Автоматизація

   Деплой, резервні копії, продовження сертифікатів і моніторинг налаштовані так, щоб працювати без чиєїсь пам'яті про те, що їх треба запустити. Саме це не дає тим самим проблемам повернутися.

4. Документація

   Де що міститься, як деплоїти, як відновлювати, кому телефонувати. Написано так, щоб це прочитав ваш наступний адміністратор, а не щоб довести факт виконання робіт.

5. Супровід

   Регулярні оновлення, моніторинг і заздалегідь описаний порядок дій при аварії — або чиста передача справ вашій команді. Обидва варіанти нормальні; ненормально — не опинитися в жодному з них.