Багато років тому, коли локальні сервери Unix із великими файловими системами були справою, компанії розробляли широкі правила керування папками та стратегії для адміністрування прав доступу до різних папок для різних людей.
Зазвичай платформа організації обслуговує різні групи користувачів із абсолютно різними інтересами, обмеженнями рівня конфіденційності або визначеннями вмісту. У випадку глобальних організацій це може навіть означати розділення вмісту на основі місцезнаходження, тобто, в основному, між користувачами, які належать до різних країн.
Додаткові типові приклади можуть включати:
- розділення даних між середовищами розробки, тестування та виробництва
- продажний контент, недоступний для широкої аудиторії
- законодавчий вміст конкретної країни, який не можна побачити або отримати доступ з іншого регіону
- контент, пов’язаний з проектом, де «дані про лідерство» мають надаватися лише обмеженій групі людей тощо.
Існує потенційно нескінченний список таких прикладів. Справа в тому, що завжди існує якась потреба розподілити права доступу до файлів і даних між усіма користувачами, яким платформа надає доступ.
У випадку локальних рішень це було рутинним завданням. Адміністратор файлової системи просто встановив деякі правила, використав обраний інструмент, а потім людей було зіставлено в групи користувачів, а групи користувачів зіставлено у список папок або точок монтування, до яких вони матимуть доступ. Попутно рівень доступу був визначений як доступ лише для читання або доступ для читання та запису.
Тепер, дивлячись на хмарні платформи AWS, очевидно, що люди будуть мати схожі вимоги щодо обмежень доступу до вмісту. Але тепер рішення цієї проблеми має бути іншим. Файли більше не зберігаються на серверах Unix, а в хмарі (і потенційно доступні не лише для всієї організації, але навіть для всього світу), а вміст зберігається не в папках, а у відрах S3.
Нижче наведено альтернативний підхід до цієї проблеми. Він побудований на реальному досвіді, який я отримав, коли розробляв такі рішення для конкретного проекту.
Простий, але значною мірою ручний підхід
Один із способів вирішення цієї проблеми без будь-якої автоматизації відносно простий і простий:
- Створіть нове відро для кожної окремої групи людей.
- Призначте права доступу до відра, щоб лише ця конкретна група мала доступ до відра S3.
Це, безумовно, можливо, якщо вимога полягає в дуже простому та швидкому розв’язанні. Проте є деякі обмеження, про які слід знати.
За замовчуванням в одному обліковому записі AWS можна створити лише до 100 сегментів S3. Цей ліміт можна збільшити до 1000, надіславши збільшення ліміту обслуговування до квитка AWS. Якщо ці обмеження не викликають занепокоєння у вашому конкретному випадку впровадження, тоді ви можете дозволити кожному з ваших окремих користувачів домену працювати в окремому сегменті S3 і припинити роботу.
Проблеми можуть виникнути, якщо існують групи людей із міжфункціональними обов’язками або просто деякі люди, яким потрібен доступ до вмісту кількох доменів одночасно. Наприклад:
- Аналітики даних, які оцінюють вміст даних для кількох різних областей, регіонів тощо.
- Команда тестування ділиться послугами, обслуговуючи різні групи розробників.
- Повідомлення про користувачів, які потребують створення аналізу інформаційної панелі на основі даних про різні країни в одному регіоні.
Як ви можете собі уявити, цей список знову може зростати настільки, наскільки ви можете собі уявити, а потреби організацій можуть створювати різноманітні варіанти використання.
Чим складнішим стає цей список, тим складніша оркестровка прав доступу буде потрібна для надання всім цим різним групам різних прав доступу до різних сегментів S3 в організації. Будуть потрібні додаткові інструменти, і, можливо, навіть спеціальний ресурс (адміністратор) потребуватиме підтримувати списки прав доступу та оновлювати їх щоразу, коли надходитимуть будь-які зміни (що буде дуже часто, особливо якщо організація велика).
Отже, як досягти того ж більш організованим і автоматизованим способом?
Якщо підхід сегментів для кожного домену не спрацює, будь-яке інше рішення призведе до спільних сегментів для більшої кількості груп користувачів. У таких випадках необхідно вибудувати цілу логіку призначення прав доступу в якійсь області, яку легко динамічно змінювати або оновлювати.
Одним із способів досягти цього є використання тегів на сегментах S3. Теги рекомендується використовувати в будь-якому випадку (якщо ні для чого іншого, як для полегшення категоризації виставлення рахунків). Однак тег можна змінити будь-коли в майбутньому для будь-якого сегмента.
Якщо вся логіка побудована на основі тегів відра, а решта конфігурації залежить від значень тегів, динамічна властивість гарантується, оскільки можна перевизначити призначення відра, просто оновивши значення тегів.
Які теги використовувати, щоб це працювало?
Це залежить від конкретного випадку використання. Наприклад:
- Це може знадобитися для розділення відер за типом середовища. Отже, у такому випадку одне з імен тегів має бути щось на зразок «ENV» і з можливими значеннями «DEV», «TEST», «PROD» тощо.
- Можливо, ви хочете розділити команду за країною. У такому випадку інший тег буде «COUNTRY» і матиме значення певної країни.
- Або ви можете розділити користувачів на основі функціонального відділу, до якого вони належать, як-от бізнес-аналітики, користувачі сховищ даних, спеціалісти з обробки даних тощо. Тому ви створюєте тег із назвою «USER_TYPE» і відповідним значенням.
- Іншим варіантом може бути те, що ви бажаєте явно визначити фіксовану структуру папок для певних груп користувачів, які вони повинні використовувати (щоб не створювати власний безлад папок і не губитися там з часом). Ви можете зробити це знову за допомогою тегів, де ви можете вказати кілька робочих каталогів, наприклад: «дані/імпорт», «дані/оброблені», «дані/помилка» тощо.
В ідеалі ви хочете визначити теги так, щоб їх можна було логічно об’єднати та створити цілу структуру папок у відрі.
Наприклад, ви можете поєднати такі теги з наведених вище прикладів, щоб створити спеціальну структуру папок для різних типів користувачів із різних країн із попередньо визначеними папками імпорту, які вони, як очікується, використовуватимуть:
- /
/ / /
Просто змінивши значення
Це дозволить використовувати те саме відро для багатьох різних користувачів. Відра не підтримують папки явно, але вони підтримують «мітки». Зрештою, ці мітки працюють як вкладені папки, оскільки користувачам потрібно пройти через ряд міток, щоб отримати доступ до своїх даних (так само, як вони робили б із вкладеними папками).
Визначивши теги в певній придатній для використання формі, наступним кроком є створення політик відра S3, які використовуватимуть теги.
Якщо політики використовують імена тегів, ви створюєте щось під назвою «динамічні політики». По суті, це означає, що ваша політика поводитиметься по-різному для сегментів із різними значеннями тегів, на які політика посилається у формі чи заповнювачах.
Цей крок, очевидно, передбачає певне спеціальне кодування динамічних політик, але ви можете спростити цей крок за допомогою інструмента редактора політик Amazon AWS, який проведе вас через цей процес.
У самій політиці ви захочете закодувати конкретні права доступу, які мають застосовуватися до відра, і рівень доступу таких прав (читання, запис). Логіка зчитує теги у відрах і створить структуру папок у відрі (створюючи мітки на основі тегів). На основі конкретних значень тегів будуть створені вкладені папки, а в рядку – призначені необхідні права доступу.
Приємно в такій динамічній політиці те, що ви можете створити лише одну динамічну політику, а потім призначити ту саму динамічну політику багатьом сегментам. Ця політика діятиме по-різному для сегментів із різними значеннями тегів, але завжди відповідатиме вашим очікуванням щодо сегментів із такими значеннями тегів.
Це дійсно ефективний спосіб організованого, централізованого керування розподілом прав доступу для великої кількості сегментів, де очікується, що кожне відро відповідатиме певним шаблонним структурам, узгодженим заздалегідь і використовуватимуться вашими користувачами в межах вся організація.
Автоматизуйте адаптацію нових організацій
Після визначення динамічних політик і призначення їх існуючим сегментам користувачі можуть почати використовувати ті самі пакети без ризику, що користувачі з різних груп не матимуть доступу до вмісту (збереженого в одному сегменті), розташованого в структурі папок, де вони не мають доступу.
Крім того, для деяких груп користувачів із ширшим доступом буде легко отримати доступ до даних, оскільки всі вони зберігатимуться в одному сегменті.
Останнім кроком є максимально спрощена адаптація нових користувачів, нових сегментів і навіть нових тегів. Це призвело до ще одного спеціального кодування, яке, однак, не повинно бути надто складним, припускаючи, що ваш процес адаптації має кілька дуже чітких правил, які можна інкапсулювати за допомогою простої, зрозумілої логіки алгоритму (принаймні таким чином ви можете довести, що ваш процес має певну логіку, і він не виконується надто хаотично).
Це може бути так само просто, як створення виконуваного сценарію за допомогою команди AWS CLI з параметрами, необхідними для успішного підключення нової сутності до платформи. Це може бути навіть серія сценаріїв CLI, які виконуються в певному порядку, як, наприклад:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(<тип_користувача>,<країна>,
) - тощо
Ви зрозуміли суть. 😃
Порада професіонала 👨💻
Якщо хочете, є одна професійна порада, яку можна легко застосувати до наведених вище.
Динамічні політики можна використовувати не лише для призначення прав доступу для розташування папок, але й для автоматичного призначення прав обслуговування для сегментів і груп користувачів!
Усе, що знадобиться, це розширити список тегів у відрах, а потім додати права доступу до динамічної політики для використання певних служб для конкретних груп користувачів.
Наприклад, може існувати певна група користувачів, яким також потрібен доступ до конкретного сервера кластера бази даних. Цього, безсумнівно, можна досягти за допомогою динамічних політик, що використовують пакетні завдання, тим більше, якщо доступ до сервісів керується рольовим підходом. Просто додайте до коду динамічної політики частину, яка оброблятиме теги щодо специфікації кластера бази даних і призначатиме права доступу до політики безпосередньо цьому конкретному кластеру БД і групі користувачів.
Таким чином, адаптація нової групи користувачів буде виконана лише за допомогою цієї єдиної динамічної політики. Крім того, оскільки вона є динамічною, ту саму політику можна повторно використовувати для реєстрації багатьох різних груп користувачів (очікується, що вони будуть дотримуватися того самого шаблону, але не обов’язково тих самих служб).
Ви також можете переглянути ці команди AWS S3 для керування сегментами та даними.