Зміст
- 1 Що це ключ доступу до AWS?
- 2 Як безпечно керувати ключами доступу до AWS
- 3 Ролі IAM проти користувачів IAM
- 4 Безпечне використання ключів доступу AWS
- 5 Як змінити ключі доступу AWS
- 6 Зменшення ризику під час розкриття ключів доступу AWS
- 7 Безпечне зберігання інших секретів за допомогою AWS Secrets Manager
- 8 Співробітництво з експертом для посилення безпеки вашої хмари
Інформаційна безпека в хмарі залежить від належного управління секретами, включаючи ключі доступу AWS. Щоб використовувати хмарні ресурси, авторизовані користувачі та код повинні пройти автентифікацію. Автентифікація базується на спільних секретах, але спільні облікові дані можуть створювати вразливі місця в безпеці, особливо якщо вони наївно надаються шляхом вбудовування їх у код програми.
Вбудовування ключів доступу AWS у код виглядає ефективним рішенням, коли, наприклад, ваш код має взаємодіяти з API S3 для зберігання даних у відро. Однак він відкриває ключі кожному, хто бачить код.
Ключі AWS часто розкриваються таким чином, коли код завантажується до служб контролю версій, таких як GitHub. Однак загальнодоступний код — не єдина вразливість для вбудованих ключів доступу. Будь-хто в компанії, який має доступ до коду, може переглядати облікові дані, на використання яких вони можуть не мати прав, що підриває стратегії автентифікації та контролю доступу.
Використання ключів доступу AWS у вашому коді може здатися зручним, але ризикованим, як і роздача копій ключа від будинку або залишення запасного під килимком. Якщо ваш код поширюється в Інтернеті, це все одно, що ви повідомляєте всім, де цей запасний ключ. І навіть на роботі не кожен повинен мати ключ від кожних дверей.
Нижче ми досліджуємо безпечні альтернативи вбудовуванню ключів доступу AWS та інших секретів у код.
Що це ключ доступу до AWS?
Ключі доступу є основними довгостроковими обліковими даними AWS для програмної автентифікації. Ключ доступу AWS складається з ідентифікатора ключа доступу та секретного ключа доступу; разом вони автентифікують запити до API AWS, дозволяючи користувачам взаємодіяти зі службами AWS зі свого коду, зокрема через клієнти AWS CLI та SDK.
Ключі доступу AWS пов’язані з користувачами на платформі AWS Identity and Access Management (IAM). Оскільки вони є програмним еквівалентом імені користувача та пароля, їх слід захищати з такою ж ретельністю. Так само, як ви не вставляєте свій пароль у код, вам не слід вставляти ключ доступу.
Як безпечно керувати ключами доступу до AWS
Ми розглянемо два способи безпечного керування ключами доступу до AWS. Перше — уникати їх використання взагалі, замість цього використовувати тимчасові облікові дані безпеки, пов’язані з ролями AWS. Другий використовує переваги функцій AWS для використання ключів доступу, не відкриваючи їх зайве.
Перш ніж обговорювати безпечне керування ключами, застереження щодо ключа доступу кореневого користувача: користувач кореневого IAM має необмежений доступ. доступ до кожного ресурсу AWS. Зловмисник може вимикати сервери, видаляти дані, створювати та знищувати користувачів або будь-які інші функції AWS API за допомогою ключа root-користувача.
З цієї причини вам не слід використовувати ключ root-доступу, і ви має вимкнути ключі доступу root, які вже використовуються. Насправді, це гарна практика уникати використання облікового запису root, якщо це не вкрай необхідно, як ми обговорювали в 10 найкращих порадах для покращення безпеки AWS сьогодні.
Ролі IAM проти користувачів IAM
Роль IAM — це ідентифікатор AWS із набором дозволів для надсилання запитів до ресурсів AWS, але, на відміну від користувачів AWS, ролі не пов’язані з окремою особою. Користувачі та програми можуть «прийняти» роль IAM, що дозволяє їм отримати дозволи ролі. По суті, ролі дозволяють клієнтам AWS делегувати дозволи іншим об’єктам.
Ролі мають кілька важливих переваг. По-перше, роль можна прикріпити до таких сутностей, як екземпляри EC2. Це означає, що екземпляр EC2 може запитувати ресурси відповідно до дозволів ролі, уникаючи необхідності вставляти в код ключ доступу користувача IAM до AWS.
По-друге, ролі можна використовувати для створення тимчасових облікових даних. Ключі доступу IAM є постійними, доки їх не буде видалено, тоді як тимчасові облікові дані ролі автоматично стають недійсними, щойно мине час, який можна налаштувати.
Безпечне використання ключів доступу AWS
У деяких випадках ви можете віддати перевагу використанню ключа доступу користувача IAM замість ролі AWS, але вам не слід вставляти облікові дані в код. Натомість ви можете безпечно зберігати ключ доступу в місці, яке може читати ваш код.
Один із варіантів — створити змінну середовища в робочому середовищі вашого коду для зберігання ключа. Змінними середовища керує операційна система середовища, і до них можна отримати доступ через системні бібліотеки або AWS SDK для вашої бажаної мови програмування. Кілька служб Amazon можуть використовувати AWS Secrets Manager для отримання секретів для введення в змінні середовища контейнерів та інших ресурсів.
Іншим варіантом є файл облікових даних AWS. Файл облікових даних — це текстовий файл, що містить ключ доступу. AWS SDK і AWS CLI шукатимуть файл облікових даних і використовуватимуть ключ доступу під час надсилання запитів на інші ресурси.
Ці методи — ролі, змінні середовища та файли облікових даних — підходять для різних сценаріїв, але критичний момент такий: вбудовувати ключ доступу AWS у ваш код – погана ідея.
Як змінити ключі доступу AWS
Ротація замінює старий ключ на новий і вилучає старий ключ. Ключі доступу до AWS є довгостроковими обліковими даними. У разі виявлення їх можна використовувати, доки не буде видалено користувача чи ключ. Ротація ключів обмежує корисність витоку ключів для зловмисників.
Користувачі AWS можуть змінювати ключі в IAM, не перериваючи доступу програмного забезпечення до ресурсів. Найкраще створити новий ключ доступу, оновити програмне забезпечення для використання нового ключа, а потім зробити старий ключ неактивним.
Коли користувач переконається, що все програмне забезпечення використовує новий ключ, він може видалити оригінальний ключ. Ротацію ключа доступу до AWS можна здійснити у веб-консолі IAM, AWS CLI та AWS API.
Зменшення ризику під час розкриття ключів доступу AWS
Хоча користувачі AWS можуть запобігти розкриттю ключів AWS, що їм робити, якщо ключ розкрито? По-перше, ви повинні негайно зробити ключ недійсним. Однак це також запобіжить законному використанню, що може призвести до збою в роботі служби. Витік ключів має бути визнаний недійсним якнайшвидше, але ви можете спершу захотіти повернути ключі критично важливого програмного забезпечення.
Розкритий ключ, можливо, уже використовувався, тому ви також повинні перевірити всі ресурси, до яких ключ надає доступ. Залежно від прав доступу користувача, його ключ міг дозволити зловмиснику викрасти конфіденційні дані або проникнути в шкідливе програмне забезпечення.
Нарешті, скористайтеся журналами S3 і AWS CloudTrail, щоб дослідити, чи було використано ключ, і вжити заходів для зменшення потенційних ризиків і вразливостей.
Безпечне зберігання інших секретів за допомогою AWS Secrets Manager
Вам може знадобитися безпечно керувати іншими секретами на додаток до ключів доступу AWS, включаючи ключі SSH, облікові дані бази даних і сторонні ключі API. AWS Secrets Manager надає рішення для зберігання, ротації, керування та отримання широкий вибір секретів.
Наприклад, щоб надати програмі доступ до бази даних, ви повинні зберегти облікові дані бази даних у зашифрованому вигляді в AWS Secrets Manager. Програма може запитувати диспетчер секретів, який розшифрує та поверне облікові дані бази даних через зашифроване з’єднання. Доступ до даних, що зберігаються в AWS Secrets Manager, контролюється політиками дозволів IAM для користувачів, груп і ролей, що забезпечує детальний контроль доступу.
Співробітництво з експертом для посилення безпеки вашої хмари
Щоб дізнатися більше про безпеку хмари AWS, відвідайте KirkpatrickPrice Служби безпеки AWSщоб знайти безліч освітнього контенту з хмарної безпеки та аудиту AWS.
Якщо ви хочете обговорити аудити AWS з досвідченим аудитором, зв’яжіться з KirkpatrickPrice сьогодні.
Поділитися Твіт Поділитися Електронна пошта
Пов’язані публікації
- Вимога PCI 3.5.2 – Обмежте доступ до криптографічних ключів
Вимога PCI 3.5.2 стверджує: «Обмежте доступ до криптографічних ключів найменшій кількості зберігачів…
- Чи впливають ці 8 вразливостей на вашу інфраструктуру Безпека AWS?
Уразливості AWS Веб-служби Amazon (AWS) домінують у корпоративному хмарному ландшафті. Приблизно дві третини бізнесу…
- 10 найкращих практик S3 для покращення безпеки AWS
Служба Amazon Simple Storage Service (Amazon S3) відсвяткувала свій 15-й день народження у 2021 році. S3 був…