Розслідування інциденту: 23 листопада 2021 року

Підсумки

У вівторок, 4 листопада, між 00:5 і приблизно 36:23 за тихоокеанським часом у більшості виробничих систем Coinbase стався збій. Під час цього збою користувачі не могли отримати доступ до Coinbase за допомогою наших веб-сайтів і програм, а отже, не могли використовувати наші продукти. Ця публікація має на меті описати, що сталося та причини, а також обговорити, як ми плануємо уникнути подібних проблем у майбутньому.

Інцидент

23 листопада 2021 року о 4:00 за тихоокеанським часом (24:2021 UTC 00 листопада 00 року) закінчився термін дії сертифіката SSL для внутрішнього імені хоста в одному з наших облікових записів Amazon Web Services (AWS). Сертифікат SSL із простроченим терміном дії використовувався багатьма нашими внутрішніми балансувальниками навантаження, що призвело до збою більшості міжслужбових зв’язків. Через те, що наш рівень маршрутизації API підключається до серверних служб через субдомени цього внутрішнього імені хосту, близько 90% вхідного трафіку API повертають помилки.

Рівень помилок повернувся до нормального значення, коли ми змогли перенести всі балансувальники навантаження на дійсний сертифікат.

Контекст: сертифікати в Coinbase

Корисно надати деяку довідкову інформацію про те, як ми керуємо сертифікатами SSL у Coinbase. Здебільшого сертифікати для публічних імен хостів, як-от coinbase.com, керуються та надаються Cloudflare. Для сертифікатів для внутрішніх імен хостів, які використовуються для маршрутизації трафіку між серверними службами, ми історично використовували сертифікати сервера AWS IAM.

Одним із недоліків сертифікатів сервера IAM є те, що сертифікати потрібно генерувати за межами AWS і завантажувати за допомогою виклику API. Тож минулого року наша команда інфраструктури перейшла з IAM Server Certificates на AWS Certificate Manager (ACM). ACM вирішує проблему безпеки, оскільки AWS генерує публічні та приватні компоненти сертифіката в ACM і зберігає зашифровану версію в IAM для нас. Лише підключені служби, такі як Cloudfront і Elastic Load Balancers, отримають доступ до сертифікатів. Заперечуючи acm:ExportCertificate дозвіл на всі ролі AWS IAM гарантує, що їх неможливо експортувати.

На додаток до додаткових переваг безпеки, ACM також автоматично поновлює сертифікати до закінчення терміну дії. З огляду на те, що сертифікати ACM мають поновлюватися, а ми зробили міграцію, як це сталося?

Аналіз причин

Реагувальники швидко помітили, що прострочений сертифікат був сертифікатом сервера IAM. Це було неочікувано, тому що вищезгадана міграція ACM була широко розголошена в інженерних каналах зв'язку в той час; таким чином ми працювали в припущенні, що працюємо виключно на сертифікатах ACM.

Як ми згодом виявили, одна з міграцій сертифікатів не відбулася за планом; група інженерів, які працюють над міграцією, завантажила новий сертифікат IAM і відклала решту міграції. На жаль, про затримку не так широко повідомили, як це мало бути, і зміни в структурі команди та персоналу призвели до того, що проект неправильно вважався завершеним.

Крім міграційного статусу, ви можете поставити те саме запитання, що й ми: «Чому ми не попередили про закінчення терміну дії сертифіката?» Відповідь така: ми були. Сповіщення надсилалися до групи розсилки електронною поштою, яка, як ми виявили, складалася лише з двох осіб. Ця група спочатку була більшою, але скоротилася з відходом членів команди, і вона ніколи не була достатньо поповнена, оскільки до команди приєдналися нові люди.

Коротше кажучи, термін дії критичного сертифіката закінчився через усі три фактори:

1. Перенесення IAM на ACM було не завершено.
2. Сповіщення про закінчення терміну дії надсилалися лише електронною поштою та фільтрувалися або ігнорувалися.
3. Лише дві особи були в списку розсилки електронною поштою.

Роздільна здатність і покращення

Щоб вирішити цю проблему, ми перенесли всі балансувальники навантаження, які використовували прострочений сертифікат IAM, до наявного автоматичного оновлення сертифіката ACM, який було надано як частину вихідного плану міграції. Це зайняло більше часу, ніж бажано, через кількість залучених балансувальників навантаження та нашу обережність у визначенні, тестуванні та застосуванні необхідних змін інфраструктури.

Щоб упевнитися, що ми більше не зіткнемося з подібною проблемою, ми вжили наведених нижче заходів для усунення факторів, згаданих у розділі RCA вище.

1. Ми завершили перехід на ACM, більше не використовуємо сертифікати сервера IAM і видаляємо всі застарілі сертифікати, щоб зменшити шум.
2. Ми додаємо автоматизований моніторинг, підключений до нашої системи сповіщень і пейджінгу, щоб посилити сповіщення електронною поштою. Вони з’являтимуться на сторінці, коли закінчиться термін дії, а також коли сертифікати ACM втратять право на автоматичне поновлення.
3. Ми додали постійний псевдонім групи до списку розсилки електронною поштою. Крім того, ця група автоматично оновлюється, коли співробітники приєднуються та залишають компанію.
4. Ми створюємо сховище операцій з усунення інцидентів, щоб скоротити час на визначення, тестування та застосування нових змін.

Ми дуже серйозно ставимося до безперебійної роботи та продуктивності нашої інфраструктури та наполегливо працюємо, щоб підтримати мільйони клієнтів, які обирають Coinbase для керування своєю криптовалютою. Якщо ви зацікавлені у вирішенні завдань, подібних до перелічених тут, приходьте працювати з нами.

Розслідування інциденту: 23 листопада 2021 року був спочатку опублікований в Блог Coinbase на Medium, де люди продовжують розмову, висвітлюючи та відповідаючи на цю історію.

Source: https://blog.coinbase.com/incident-post-mortem-november-23-2021-d507821b8459?source=rss—-c114225aeaf7—4