Преди години, когато локалните Unix сървъри с големи файлови системи бяха нещо, компаниите изграждаха обширни правила за управление на папки и стратегии за администриране на права за достъп до различни папки за различни хора.
Обикновено платформата на една организация обслужва различни групи потребители с напълно различни интереси, ограничения на нивото на поверителност или дефиниции на съдържанието. В случай на глобални организации това може дори да означава разделяне на съдържание въз основа на местоположение, така че основно между потребителите, принадлежащи към различни държави.
Други типични примери могат да включват:
- разделяне на данните между развойна, тестова и производствена среда
- търговско съдържание, недостъпно за широка аудитория
- специфично за държавата законодателно съдържание, което не може да бъде видяно или достъпно от друг регион
- съдържание, свързано с проекти, където „данни за лидерство“ трябва да се предоставят само на ограничена група хора и т.н.
Има потенциално безкраен списък от такива примери. Въпросът е, че винаги има някаква нужда да се организират правата за достъп до файлове и данни между всички потребители, на които платформата предоставя достъп.
В случай на локални решения това беше рутинна задача. Администраторът на файловата система просто зададе някои правила, използва инструмент по избор и след това хората бяха картографирани в потребителски групи, а потребителските групи бяха картографирани в списък с папки или точки за монтиране, до които те трябва да имат достъп. По пътя нивото на достъп беше определено като достъп само за четене или достъп за четене и запис.
Сега, разглеждайки облачните платформи на AWS, очевидно е да очакваме хората да имат подобни изисквания за ограничения за достъп до съдържание. Решението на този проблем обаче сега трябва да е различно. Файловете вече не се съпротивляват на Unix сървъри, а в облака (и потенциално достъпни не само за цялата организация, но дори и за целия свят), а съдържанието не се съхранява в папки, а в S3 кофи.
По-долу е описана алтернатива за подход към този проблем. Той е изграден върху опита от реалния свят, който имах, докато проектирах такива решения за конкретен проект.
Съдържание
Прост, но до голяма степен ръчен подход
Един от начините за разрешаване на този проблем без никаква автоматизация е сравнително ясен и прост:
- Създайте нова кофа за всяка отделна група хора.
- Задайте права за достъп до кофата, така че само тази конкретна група да има достъп до S3 кофата.
Това със сигурност е възможно, ако изискването е да се използва много проста и бърза резолюция. Има обаче някои ограничения, които трябва да знаете.
По подразбиране могат да бъдат създадени само до 100 кофи S3 под един AWS акаунт. Този лимит може да бъде удължен до 1000 чрез подаване на увеличение на лимита на услугата към билета на AWS. Ако тези ограничения не са нещо, за което вашият конкретен случай на внедряване би се притеснявал, тогава можете да позволите на всеки от отделните потребители на вашия домейн да работи в отделна кофа S3 и да го прекратите.
Проблемите могат да възникнат, ако има няколко групи от хора с междуфункционални отговорности или просто някои хора, които се нуждаят от достъп до съдържанието на повече домейни едновременно. Например:
- Анализатори на данни, които оценяват съдържанието на данни за няколко различни области, региони и т.н.
- Тестващият екип споделя услуги, обслужващи различни екипи за разработка.
- Отчитане на потребители, изискващи изграждане на анализ на таблото за управление върху различни държави в рамките на един и същ регион.
Както можете да си представите, този списък отново може да нарасне толкова, колкото можете да си представите, а нуждите на организациите могат да генерират всякакви случаи на употреба.
Колкото по-сложен става този списък, толкова по-сложна оркестрация на правата за достъп ще е необходима, за да се предоставят на всички тези различни групи различни права за достъп до различни кофи S3 в организацията. Ще са необходими допълнителни инструменти и може би дори специален ресурс (администратор) ще трябва да поддържа списъците с права за достъп и да ги актуализира всеки път, когато бъде поискана промяна (което ще бъде много често, особено ако организацията е голяма).
Тогава как да постигнем същото нещо по по-организиран и автоматизиран начин?
Ако подходът кофа на домейн не работи, всяко друго решение ще доведе до споделени кофи за повече потребителски групи. В такива случаи е необходимо да се изгради цялата логика на задаване на права за достъп в някаква област, която лесно се променя или актуализира динамично.
Един от начините за постигане на това е чрез използване на етикети на кофите S3. Етикетите се препоръчва да се използват във всеки случай (ако не за друго, освен за по-лесно категоризиране на таксуването). Етикетът обаче може да бъде променен по всяко време в бъдеще за всяка кофа.
Ако цялата логика е изградена на базата на етикетите на кофата и останалата част е конфигурация, зависима от стойностите на етикета, динамичното свойство е гарантирано, тъй като човек може да предефинира предназначението на кофата само чрез актуализиране на стойностите на етикета.
Какви тагове да използвате, за да работи това?
Това зависи от конкретния случай на употреба. Например:
- Може да е необходимо да се отделят кофи за тип среда. Така че в този случай едно от имената на таговете трябва да бъде нещо като „ENV“ и с възможни стойности „DEV“, „TEST“, „PROD“ и т.н.
- Може би искате да разделите отбора въз основа на страната. В този случай друг таг ще бъде „ДЪРЖАВА“ и ще има значение за име на държава.
- Или може да искате да разделите потребителите въз основа на функционалния отдел, към който принадлежат, като бизнес анализатори, потребители на хранилища за данни, специалисти по данни и т.н. Така че създавате етикет с името „USER_TYPE“ и съответната стойност.
- Друга опция може да бъде, че искате изрично да дефинирате фиксирана структура на папки за конкретни потребителски групи, които те трябва да използват (за да не създават свои собствени бъркотии от папки и да се изгубят там с течение на времето). Можете да направите това отново с тагове, където можете да посочите няколко работни директории като: „данни/импортиране“, „данни/обработени“, „данни/грешка“ и т.н.
В идеалния случай искате да дефинирате етикетите, така че да могат да бъдат логично комбинирани и да ги накарате да образуват цяла структура на папка в кофата.
Например, можете да комбинирате следните тагове от примерите по-горе, за да създадете специална структура на папки за различни типове потребители от различни страни с предварително дефинирани папки за импортиране, които се очаква да използват:
- /
/<ПОТРЕБИТЕЛСКИ_ТИП>/<ДЪРЖАВА>/<КАЧВАНЕ>
Просто като промените стойността
Това ще позволи използването на една и съща кофа за много различни потребители. Кофите не поддържат изрично папки, но поддържат „етикети“. Тези етикети в крайна сметка работят като подпапки, защото потребителите трябва да преминат през поредица от етикети, за да достигнат до своите данни (точно както биха направили с подпапките).
След дефиниране на таговете в някаква използваема форма, следващата стъпка е да се изградят S3 bucket политики, които ще използват таговете.
Ако правилата използват имената на таговете, вие създавате нещо, наречено „динамични правила“. Това основно означава, че вашата политика ще се държи по различен начин за кофи с различни стойности на тагове, към които политиката се отнася във форма или контейнери.
Тази стъпка очевидно включва известно персонализирано кодиране на динамичните политики, но можете да опростите тази стъпка с помощта на инструмента за редактиране на политики на Amazon AWS, който ще ви води през процеса.
В самата политика ще искате да кодирате конкретни права за достъп, които да се прилагат към кофата и нивото на достъп на тези права (четене, писане). Логиката ще прочете етикетите на кофите и ще изгради структурата на папките в кофата (създаване на етикети въз основа на таговете). Въз основа на конкретните стойности на таговете ще бъдат създадени подпапките и необходимите права за достъп ще бъдат зададени по реда.
Хубавото на такава динамична политика е, че можете да създадете само една динамична политика и след това да присвоите същата динамична политика на много кофи. Тази политика ще се държи по различен начин за кофи с различни стойности на тагове, но винаги ще отговаря на вашите очаквания за кофа с такива стойности на тагове.
Това е наистина ефективен начин за управление на присвояването на права за достъп по организиран, централизиран начин за голям брой кофи, където се очаква, че всяка кофа ще следва някои шаблонни структури, които са договорени предварително и ще бъдат използвани от вашите потребители в рамките цялата организация.
Автоматизирайте въвеждането на нови обекти
След като дефинират динамични политики и ги присвоят на съществуващите кофи, потребителите могат да започнат да използват едни и същи кофи, без риск потребителите от различни групи да нямат достъп до съдържание (съхранено в една и съща кофа), разположено под структура на папки, където нямат достъп.
Освен това за някои потребителски групи с по-широк достъп ще бъде лесно да достигнат до данните, защото всички те ще се съхраняват в една и съща кофа.
Последната стъпка е да направите включването на нови потребители, нови кофи и дори нови тагове възможно най-лесно. Това води до друго персонализирано кодиране, което обаче не е необходимо да бъде прекалено сложно, ако приемем, че вашият процес на включване има някои много ясни правила, които могат да бъдат капсулирани с проста, ясна алгоритъмна логика (поне можете да докажете по този начин, че вашият процесът има някаква логика и не е направен по прекалено хаотичен начин).
Това може да бъде толкова просто, колкото създаването на изпълним скрипт чрез AWS CLI команда с параметри, необходими за успешното включване на нов обект в платформата. Може дори да бъде поредица от CLI скриптове, изпълними в определен ред, като например:
- create_new_bucket(
, , , , ..) - create_new_tag(
, , ) - update_existing_tag(
, , ) - create_user_group(
, , ) - и т.н.
Разбирате смисъла. 😃
Професионален съвет 👨💻
Има един професионален съвет, ако желаете, който може лесно да се приложи върху горния.
Динамичните политики могат да се използват не само за присвояване на права за достъп до местоположения на папки, но и за автоматично присвояване на права за обслужване за кофи и потребителски групи!
Всичко, което би било необходимо, е да се разшири списъкът с тагове на кофите и след това да се добавят динамични права за достъп до политики, за да се използват конкретни услуги за конкретни групи потребители.
Например, може да има някаква група потребители, които също се нуждаят от достъп до конкретния сървър на клъстер на база данни. Това несъмнено може да бъде постигнато чрез динамични политики, използващи кофи задачи, още повече, ако достъпът до услугите се ръководи от ролеви подход. Просто добавете към кода на динамичната политика част, която ще обработва тагове по отношение на спецификацията на клъстера на базата данни и ще присвоява привилегиите за достъп до политиката директно на този конкретен DB клъстер и потребителска група.
По този начин включването на нова потребителска група ще бъде изпълнимо само от тази единствена динамична политика. Освен това, тъй като е динамична, една и съща политика може да се използва повторно за включване на много различни потребителски групи (очаква се да следват същия шаблон, но не непременно същите услуги).
Може също да разгледате тези AWS S3 команди за управление на кофи и данни.