CapordiaНазвіть відповідальних перед розподілом доступів
Розрізняйте відповідального за справу оренди, особу, яка дозволяє доступ до проєкту, та особу, яка може вносити технічні зміни на цільовій системі. Відповідальний за результати не обов'язково має запускати процеси чи адмініструвати машину. Опишіть потрібні операції, перш ніж обирати права: читати експорт, додавати вхідні дані, виконувати завдання чи змінювати середовище.
Потім перевірте обсяг фактично наданих доступів. Якщо ви не маєте права створювати ідентичності чи налаштовувати дозволи, дочекайтеся підтвердження можливої процедури, перш ніж запрошувати інших учасників. Не обходьте це обмеження, роздаючи пароль облікового запису Capordia. Розподіл роботи та ведення комерційної справи — це два різні питання.
Використовувати індивідуальну ідентичність і знати її межі
Індивідуальна ідентичність дає змогу відкликати доступ однієї особи, не замінюючи доступи всієї команди. В організації SSH за ключами OpenSSH розрізняє відкритий ключ, відомий серверу, і закритий ключ, який зберігає користувач. Координаційний документ може містити посилання або відбиток відкритого ключа; він ніколи не повинен містити закритий ключ або його парольну фразу.
Два різні ключі, що надають доступ до одного системного облікового запису, не створюють автоматично двох різних периметрів файлів. Дозволи залежать від облікового запису та механізмів, налаштованих на машині. Тож вирішіть, чи вимога стосується лише індивідуальної автентифікації, чи також розмежування дій. Для автоматизацій передбачте явну ідентичність і власника, не використовуючи потай особисту ідентичність колеги.
Перевірити ціль, перш ніж подавати їй ідентичність
Під час першого доступу перевірте ім'я машини, очікуваний обліковий запис і відбиток її ключа хоста за довідкою з довіреного джерела, отриманою в процесі передавання доступів. Цей ключ хоста ідентифікує сервер; він відрізняється від вашого ключа користувача. Несподіване повідомлення про зміну ідентичності сервера варте перевірки, а не автоматичного видалення відомої довідки.
OpenSSH зберігає ключі хостів і повідомляє про їхні зміни. Використовуйте цю інформацію з урахуванням контексту: оголошена перебудова машини, змінена адреса чи нез'ясована подія. Якщо зміна неочікувана, дочекайтеся її підтвердження, перш ніж продовжити. Мета не в тому, щоб додати ритуал до кожного з'єднання, а в тому, щоб не сприймати попередження про ідентичність як просту прикрість відображення.
Вигаданий приклад: три учасники, три потреби
Вигадана команда «Справа про видання» готує тиждень роботи. Ідрісс виконує обробки проєкту A, Ноемі переглядає експорти, а Саша тимчасово залучається для налаштування середовища. Команда хоче прав із таблиці, але має перевірити, чи вони застосовні із системою, яку справді передано. Ідеться не про наявні клієнтські облікові записи й не про функції керування командою, оголошені Capordia.
Визначальний принцип полягає в тому, що Ноемі не отримує адміністративного доступу, щоб відкрити результат, і що залучення Саші має завершення. Саме лише людське схвалення не налаштовує жодних прав: технічний керівник застосовує наявні механізми, а потім кожен виконує передбачені перевірки. Якщо бажане розмежування неможливо реалізувати, проєкт має змінити свою організацію, перш ніж вводити дані, які вимагають такого розмежування.
| Учасник | Потреба | Бажаний периметр | Перегляд |
|---|---|---|---|
| Ідрісс, експлуатація | Завантажувати вхідні дані та запускати проєкт A | Робочий простір A, без загального адміністрування | Завершення кампанії або зміна ролі |
| Ноемі, валідація | Читати передані експорти | Затверджені результати, без зміни вхідних даних | Завершення валідації |
| Саша, залучення | Підготувати дозволене середовище | Визначена й затверджена зміна | Одразу після отримання завдання |
Підготувати картку доступу й перевірити межі
Картка пов'язує особу або автоматизацію, технічну ідентичність, затверджувача, периметр, обґрунтування та строк. Зберігайте посилання на відкритий ключ і процедуру відкликання, не зберігаючи секретів. OpenSSH ssh-keygen дає змогу показати відбиток відкритого ключа: це посилання допомагає позначити потрібний ключ під час додавання чи видалення, не копіюючи його закриту частину.
Перевірте дозволену дію на синтетичному файлі, а потім дію, навмисно поза периметром, яка має бути відхилена. Для ролі читання відкриття має працювати, а контрольована спроба зміни має бути відхилена. Не використовуйте реальні дані для перевірки заборони видалення. Перевірте також спільні шляхи та призначення вихідних даних, адже правильне право на теку не гарантує всіх шляхів програми.
Планувати відкликання та перевіряти нове підключення
Ініціюйте відкликання після завершення робіт, після виходу людини або за підозри на компрометацію. Відповідальний визначає всі відповідні дозволи, зокрема інші дозволені шляхи доступу для цієї самої особи. Він застосовує відкликання відповідно до фактичної конфігурації. Директива RevokedKeys в OpenSSH — це один із можливих механізмів серед документованих; не слід вважати, що вона активна на машині без перевірки.
Потім переконайтеся, що нова автентифікація з відкликаною особою відхиляється, не видаляючи доступ відповідального для відновлення. Окремо перегляньте вже відкриті сеанси, поточні завдання та ідентичності автоматизації: відкликати дозвіл і зупинити діяльність — це різні рішення. Якщо робота має продовжуватися, передайте відповідальність за неї за узгодженою процедурою, а не залишайте ідентичність без власника.
Уникати спрощень, які унеможливлюють контроль
Спільний приватний ключ не дає змоги знати, хто має його замінити, і часто змушує до колективної ротації. Широкий доступ «на час» зазвичай триває, якщо ніхто не встановив дату його перегляду. Обліковий запис для перевірки, який також використовується для адміністрування машини, ускладнює тлумачення перевірок розмежування. Виправте ці проблеми в описі доступу, перш ніж вони стануть залежністю експлуатації.
Також уникайте додавання пересилання агента, тунелів або винятків доступу лише для обходу недіагностованої проблеми. Нехай уповноважений відповідальний опише потребу в підключенні та її обмеження. Цей посібник не пропонує універсальної конфігурації сервера: механізми залежать від наданих прав, середовища та вимог проєкту. Загальна документація не замінює перевірку на цільовій системі.
Передати організацію доступу, яка залишається перевірюваною
Під час приймання зберіть затверджену матрицю, активні ідентичності, дозволені та відхилені тести, строки та особу, здатну відкликати доступ. Переконайтеся, що відсутню людину можна замінити без поширення її секрету. Безперервність спирається на процедуру та уповноваженого резервного відповідального, а не на пароль, спільний у папці проєкту.
Під час передачі справ перегляньте доступи, що стали непотрібними, та автоматизації, які залежать від персональної ідентичності. Якщо неочікувана відмова блокує роботу, складіть цільовий звіт про інцидент із технічною ідентичністю, відповідним шляхом і очищеною помилкою. Не додавайте загальних прав лише для того, щоб усунути симптом. Правильне завершення — це необхідний, перевірений доступ із відомим строком дії.
Запитання для ухвалення рішення
Чи слід ділити обліковий запис Capordia з усіма виконавцями?
Ні. Супровід оренди та технічні доступи до роботи слід організовувати окремо. Визначте можливі машинні ідентичності з фактично наданими правами. Цей метод не передбачає жодної системи запрошень або командних ролей у просторі Capordia.
Чи надає публічний ключ автоматично правильні права?
Ні. Він слугує для автентифікації, коли його дозволено; доступні дії далі залежать від облікового запису та дозволів системи. Перевірте дозволену дію та дію, яку слід відхилити, на синтетичних файлах.
Що перевірити після виходу виконавця?
Відкличте його дозволи, перевірте відхилення нової автентифікації та перегляньте сеанси, роботи й автоматизації, ще пов’язані з його ідентичністю. Збережіть уповноваженого відповідального для відновлення та супроводу. Не робіть висновку про відкликання лише на підставі поставленої позначки.