Вступ

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

Нещодавно наш давній клієнт, Inspire Commerce, розробив новий бізнес-план, який вимагає, щоб їх додаток відповідав суворим вимогам Індустрії платіжних карт (PCI) рівня 1 безпеки для обробки, передачі та зберігання інформації про кредитні картки. Багато вимог безпеки, викладених у стандарті PCI Data Security Standard (DSS), мотивують значну зміну мислення від згаданого вище скороченого фокусованого стеку. У цій статті ми коротко перелічимо деякі з цих деталей та опишемо наші рішення.

PCI DSS розділений на 12 розділів, які охоплюють все: від конфігурації брандмауерів до політик безпеки персоналу. Я коротко розгляну деякі розділи, які стосуються хостингового стеку.

1. Встановити та підтримувати конфігурацію брандмауеру для захисту даних власників карток

Це досить детальний розділ DSS, який передбачає встановлення та налаштування брандмауерів на всіх мережевих пристроях, від робочих станцій до маршрутизаторів та серверів. Використовуючи Amazon Web Services (AWS) Elastic Compute Cloud (EC2) як основу нашого хостингового стеку, багато з цих мережевих пристроїв абстрагуються від нашого поля зору або контролю. Зручно, що AWS сам відповідає PCI рівня 1, залишаючи багато цих деталей інженерам Amazon.

Однак брандмауери для вузлів EC2 вимагають деякої уваги. Вузли EC2 захищаються брандмауером, реалізованим на рівні гіпервізора та налаштованим групами безпеки AWS. Наша базова група безпеки має всі порти, які відкидають пакети, за винятком 22, 80 та 443, які приймають з усіх джерел. Ми використовуємо Ubuntu Linux на наших вузлах, і з коробки у нас налаштований IP Tables брандмауер з відкритою політикою.

PCI DSS зосереджується на використанні брандмауерів для створення безпечних приватних мереж або демілітаризованих зон (DMZ) для систем, які обслуговують додатки, що обробляють дані платіжних карток. Групи безпеки AWS забезпечують корисний механізм для створення безпечних приватних мереж між різними компонентами стеку додатків. Наприклад, створюючи WEB-групу безпеки та DB-групу безпеки та відкриваючи порт бази даних у DB-групі безпеки лише для джерел WEB-групи безпеки, брандмауер гіпервізора EC2, який працює на сервері бази даних, дозволить доступ до бази даних лише з веб-серверів, підключених до внутрішнього приватного мережевого інтерфейсу.

Для забезпечення відмовостійкості ми віддзеркалюємо конфігурацію групи безпеки AWS для брандмауера гіпервізора EC2 з сервісом CloudPassage, який може керувати брандмауером IP Tables на рівні операційної системи систем, які обслуговують компоненти додатків для обробки карток. CloudPassage організовує політики брандмауерів у Server Groups, які дещо аналогічні групам безпеки AWS. Ще однією чудовою функцією CloudPassage є сервіс GhostPorts. Ми налаштовуємо політику ssh-порту в CloudPassage для приймання з'єднань з джерел GhostPort. Щоб клієнтська машина стала джерелом GhostPort, користувач на цій машині повинен пройти автентифікацію в порталі CloudPassage, бути авторизованим для відкриття GhostPorts для групи серверів та пройти автентифікацію з зареєстрованим ключем Yubikey або відповісти на SMS-виклик з зареєстрованим мобільним телефоном. Після успішної автентифікації та авторизації CloudPassage налаштовує IP Tables для приймання з'єднань з IP-адреси джерела клієнтської машини. Це зручний, безпечний, тимчасовий та прозорий спосіб керувати доступом до чутливих хостів.

2. Не використовуйте стандартні налаштування постачальника для системних паролів та інших параметрів безпеки

Цей розділ, здається, досить очевидний. Хорошим прикладом важливості зміни стандартного пароля постачальника є стандартний пароль Splunk Universal Forwarder changeme.

Однак у цьому розділі приховане важливе вимогу до хостингу, яке дещо не пов'язане з назвою розділу. "2.2.1 Реалізуйте лише одну основну функцію на сервері, щоб запобігти співіснуванню функцій, які вимагають різних рівнів безпеки, на одному сервері. (Наприклад, веб-сервери, сервери баз даних та DNS повинні бути реалізовані на окремих серверах)."

Як згадувалося вище, групи безпеки AWS роблять завдання безпечного розділення послуг, таких як веб-сервери та сервери баз даних, на окремі хости досить простим.

5. Використовуйте та регулярно оновлюйте антивірусне програмне забезпечення

ClamAV швидко справляється з цією вимогою на Ubuntu Linux.

8. Присвоїти унікальний ідентифікатор кожній особі з доступом до комп'ютера

Мета цього розділу полягає в забезпеченні можливості аудиту та відповідальності шляхом видалення спільних користувацьких облікових записів. Оскільки ми використовуємо ключовий механізм автентифікації для безпечного доступу до оболонки, є три основні занепокоєння щодо того, хто що зробив. Спочатку необхідно запобігти можливості користувачам перемикатися на інший користувацький обліковий запис за допомогою команди su. Це легко зробити, видаливши права на виконання на су-бінарник та змінивши /etc/pam.d, щоб запобігти всім su-авторизаціям. По-друге, переконайтеся, що файли authorized_keys для всіх користувацьких облікових записів містять лише один запис. І нарешті, переконайтеся, що всі ключі, які використовуються для безпечного доступу до оболонки, захищені паролем, і що існує політика, яка забороняє поділ ключів між користувачами.

Тепер Linux Audit Daemon (AuditD) можна використовувати для відстеження системної діяльності конкретних користувачів.

9. Обмежити фізичний доступ до даних власників карток

Назва цього розділу досить самоописна. Основні теми цього розділу стосуються обмеження фізичного доступу до дата-центру для авторизованого персоналу. Подібно до обговорення конфігурації брандмауерів мережевих пристроїв вище, це покривається сертифікацією AWS PCI рівня 1, і деталі можна залишити Amazon.

10. Відстежувати та моніторити весь доступ до мережевих ресурсів та даних власників карток

Мотивація цього розділу полягає в "запобіганні, виявленні або мінімізації впливу компрометації даних". Це включає такі теми, як ведення журналів, управління цілісністю файлів та виявлення вторгнень. Наша стратегія починається з використання сервісу журналування для підтримки агрегації журналів, збереження журналів, а також пошуку записів журналів. Ми використовуємо додаток Splunk для цієї функціональності. Ми налаштували інстанс EC2 для сервера журналування та встановили Splunk. Ми налаштували групи безпеки AWS і CloudPassage ServerGroups для нового сервера, який має порт слухача Splunk, що приймає з'єднання з джерел веб-сервера та сервера бази даних на приватному мережевому інтерфейсі. Потім ми налаштували Splunk Universal Forwarder на веб-серверах та серверах баз даних і налаштували форвардери для моніторингу журналів додатків, apache, mongodb, sys, audit та auth.

Для моніторингу цілісності файлів та виявлення вторгнень ми встановили додаток OSSEC на всіх наших серверах та додали всі журнали, які пише OSSEC, до форвардерів Splunk.