Человек и машина

#машины_разное

"...back in the ‘90s, one of IBM’s Redbooks stated that the “happy path” for any piece of software comprised less than 20 percent of its code; the rest was dedicated to error handling and resilience."

Эти строки из поста про "Отрицательную инженерию" напомнили мне про одну занятную историю с платежными методами.

Средний пользователь имеет 2, максимум 3, подключенных платежных метода, будь то банковская карта, Apple/Google Pay и иже с ним. Спроектировать систему работы с платежными инструментами не так уж сложно, ориентируясь на такой профиль пользователя.

Но со временем появляется тот мизерный процент пользователей с невероятным количеством методов, уникальными способами оплаты с разных мест и прочие corner case'ы, которые предусмотреть невозможно, заложить в систему избыточно...

А чинить и доводить до ума все равно надо.

Пост выше - хороший набор аргументов для продавливания повыше в беклоге задач по оплате технического долга и доведении систем до ума. Пользуйтесь на здоровье.

#машины_разное

Есть проблема, когда SSD отваливается ровно через 40 000 часов использования.

Есть проблема, когда SSD отваливается ровно через 32 768 часов использования.

И эти проблемы не связаны: While the failure mode is similar, this issue is unrelated to the SSD issue detailed in this Customer Bulletin released in November 2019, which describes an SSD failure at 32,768 hours of operation.

Как хорошо, когда #железопроблемы тебя не касаются.

​​#пятничное #машины_разное

Когда тебя спрашивают, чем мониторинг отличается от observability.

#деньги #машины_разное #машины_aws

Когда мы говорим о запрете трафика куда угодно наружу и внутрь, мы имеем в виду ANY/ANY правила на межсетевых экранах.

PCI-DSS требует жесткого контроля над входящим и исходящим трафиком в безопасный периметр. Удовлетворить это требование можно двумя способами.

Первый способ подразумевает очевидное: прокси и фаерволы; второй же допускает реактивный подход. Вместо того, чтобы разрешать трафик на определенные адреса, мы можем сделать правило, например, разрешающее весь исходящий HTTPS трафик. Однако мы будем держать белый список и проверять весь трафик на соответствие этому списку. В случае подозрительного пакетов, дергаем дежурного, чтобы он пошел и посмотрел, что там такое происходит.

Что использование прокси, что мониторинг трафика несут с собой определенные удобства и неудобства. С прокси суть тот же белый список, что требует дополнительной работы при интеграции с новой платежной системой, особенно если та находится за поставщиком DDOS защиты навроде Akamai. С мониторингом трафика получаем неприятный опыт дежурства.

Мониторинг безопасности сам по себе необходим, и PCI-DSS по сути требует от нас делать то, что мы и так должны делать. Взять к примеру доступ к инфраструктуре, где лежат реальные данные клиентов. Людям/операторам там делать нечего, за исключением случае дешифровки данных по запросу властей, а значит каждый такой доступ должен отправлять уведомление дежурному.

Если мы развернули систему токенизации в облаке, то подобный мониторинг должен быть не только на уровне самих узлов (доступ по SSH), но и на уровне самого клавда - sts:AssumeRole “опасных” ролей или в целом подозрительные API вызовы.

Важно помнить, что приглядывать надо не только за правами дающими доступ к картам, но и правам дающим администраторский доступ.

В конце концов скомпроментированный сотрудник может просто напросто выключить мониторинг, слить данные, включить мониторинг обратно.

#деньги

Как я уже говорил, PCI-DSS касается не всех. Если вы открыли небольшой магазин плюшевых игрушек, запустили его в сети и принимаете не более 300 тысяч платежей в год, вам и заморачиваться особо не надо. Многие в таком случае отдают процессинг платежей сторонним поставщикам, будь то SberPay, Яндекс.Касса в России, или Adyen, Mollie, Stripe и прочие в ЕС/США.

Мелким товарищам так проще всего и относительно дешево. На больших объемах все куда хуже и очень дорого.

Итак, задача: не допустить утечки платежных данных, чтобы всякие сволочи не получили к ним доступ. Имеем в виду, что каждый год ждем QSA с визитом, за что мы, кстати, сами платим из своего кармана.

Первое и самое умное, что нужно сделать: огородить отдельно тот кусок инфраструктуры, который будет участвовать в платежах, это сильно упростит ежегодную оценку, да и в целом на малых просторах проще применять практики безопасности. Набираем команду, которая присягает на верность PCI-DSS и всеми правдами и неправдами защищает данные. Чаще всего эта команда поднимает инфраструктуру в клавде, который обладает PCI-DSS.

Вот тут надо сделать остановку. PCI-DSS допускает игнорировать часть требований, если вы используете поставщика, который им удовлетворяет. Иными словами, если взять тот же AWS, то никто не будет требовать вас соответствовать требованиям физической безопасности ЦОД, об этом уже позаботился AWS.

Вторая тонкость заключается в разделении ролей. Мы имеем тех, кто имеет доступ к реальным данным, то есть они могут их расшифровать при необходимости, и тех, кто пишет код, работающий с платежными данными. Эти роли не должны пересекаться: либо пиши код, либо кати в прод.

В нашей огороженной инфраструктуре строится сервис жетонизации токенизации, куда на вход приходит зашифрованная на клиенте платежная информация, расшифровывается, зашифровывается уже с другим ключом и кладется в базу. На выход клиенту отдаётся токен - уникальный идентификатор карты, который может и будет использоваться для платежей внутри, но абсолютно бесполезен снаружи. Сама платежная информация все это время хранится в защищенном периметре и не покидает его никогда, за исключением отправки запроса в платежную сеть.

Помимо этого мы имеем ряд других требований: регулярно проводить проверку на проникновение, обновлять пакеты и ядро ОС, вести учет изменений в системе (GitOps в помощь), кучу бумажной и процедуральной волокиты, запрет на трафик куда угодно и мониторинг безопасности.

Последние два момента я раскрою в следующем посте, но тут я хочу подчеркнуть важную деталь.

Именно токенизация и шифрование выступают гарантами безопасности данных. Токен можно спокойно светить в логах, вне инфраструктуры он не имеет никакой ценности, а внутри инфраструктуры у вас описаны политики, т.е. какой доступ есть у каких сервисов. Например, хорошей практикой является использовать один сервис для сохранения платежных карт, а другой для инициации платежей.

Так что если вы увидите сырые данные карточек в открытом виде, то либо это внутренний слив, либо поставщик платежей абсолютно не следовал требованиям PCI-DSS.

#деньги

Возвращаюсь к надежности платежных систем.

Однажды, устав компенсировать чарджбеки за фрод на банковских картах, лучшие умы AmEx, Visa и MasterCard решили создать консилиум под названием PCI (Payment Card Industry) Security Standards Council, в рамках которого начали разрабатывать стандарты безопасности.

PCI-DSS (Data Security Standard), в целом сложен, потому как подразумевает защиту данных на всех уровнях, как программных, так и физических.

Тут надо сделать небольшую паузу и уточнить неочевидное: не вся коммерция, принимающая оплату с помощью платежных карт, подвержена регуляторным требованиям; все зависит от объема платежей через оных. Не скажу наверняка, но "стартовый порог" - 6 миллионов долларов США. Ниже либо вообще ничего не надо делать, либо достаточно заполнить опрос онлайн.

Но это скучно! Куда лучше, когда к тебе приходит ОЦЕНЩИК.

Да-да, PCI терпеть ненавидит слово аудит, и компании проходят так называемую оценку. Семантика здесь играет роль: аудитор ищет нарушения, в то время как оценщик держит в руках список требований и собирает доказательства того, что контора добросовестно выполняет требования. Презумпция невиновности против декларативности.

Такие оценщики называются PCI QSA (Qualified Security Assessor). В конторах с особо крупными объёмами хранимых данных и платежей, есть как внутренние QSA, так и внешние. Внутренние оценщики регулярно следят за порядком и выступают основным контактом во время внешней оценки.

Что касается требований PCI-DSS, то их можно упрощенно разбить на такой список:
- Есть то, что можно хранить, например номер и срок действия карты, и что категорически нельзя, например CVC.
- Все данные шифруются от и до с момента, как данные карточки были введены. Читай, encryption-in-transit и encryption-at-rest.
- В открытом виде данные платежных карт не должны нигде проскакивать, за исключением особых случаев, например, передачи данных гос. органам.
- Компания-обработчик обязуется проводить регулярные испытания на уязвимость.
- Имеется мониторинг безопасности.

Я раскрою подробности в следующем посте, но самое любимое требование - не светить открытыми данными. Вы не поверите, но были времена, когда номера карт в открытом виде валялись в логах.

Зуб даю, где-нибудь и сейчас валяются.

#пятничное

Мальчик: изучает WAF.
Мужчина: изучает WAF.

Credits to @sergdudk

#машины_разное

Группа черных шапок, известная в определенных кругах как NB65, некоторое время назад сообщила о взломе защищенного периметра Qiwi и утечке платежных данных.

Об этом написали несколько Телеграмм каналов (например), после чего шум быстро поутих. По моей информации из Qiwi ничего не утекало, сами Paysystem Tech какой-либо связи с Qiwi не имеют (сайт у них какой-то мутный вдобавок, они живы вообще?).

Если у вас есть другая информация, поделитесь со мной в ЛС или в комментариях.

NB65 выложил полученные платежные данные в открытый доступ (сами нагуглите). В комментариях тут же набежали оглоеды в надежде получить номер карты, срок действия, CVV и заняться богомерзким фродом, но их ожидает разочарование, ведь CVV там нет.

А все потому что по правилам PCI-DSS, хранение CVV кодов даже в системе токенизации запрещено. :) Утекший номер и дедлайн карточки все еще является критической информацией, он попадает под PCI и PII (персональные) данные, но простому хитрозадому болванчику с ними ничего особо не сделать.

Учитывая вышесказанное, неудивительно, что потуги хакеров не получили никакой реакции, кроме общественной ;)

Если интересно, ставьте огонечки под этим постом, расскажу, как предприятия защищают платежные данные, и почему нынче так мало настоящих дампов платежных карт (по крайней мере в открытом доступе).

#машины_aws

Половину огоньков мы набрали. Пожалуй, этого хватит, чтобы запитать затею на английскую версию произошедшего. 🙂

Вашему вниманию очередной инцидент с AWS, который мне пришлось разобрать.

Вынужден признать, что из-за таких приключений лучшие умы Большого Теха ™ с недоверием относятся к managed service’ам облачных провайдеров.

#машины_разное #люди

Брендан Грегг таки не разочаровал и теперь будет работать в Intel.

Учитывая его вовлеченность в производительность систем от железа до программ, можно ждать новый виток нововведений от Intel. Брендан обещает тесную работу с AWS, так что ждем интересных новостей.

Это отличное решение для Intel в первую очередь. Надеюсь, экспертиза Грегга поможет конторе занять конкурирущющие позиции с многочисленными ARM производителями.

#машины_aws

Вчера проводили разбор вот этого инцидента, только раза со второго удалось объяснить сущности и хитрости поведения CodeDeploy - я натурально смотрел события в CloudTrail, чтобы понять мозги этой дуры.

Самое “приятное”: я за всю карьеру не написал столько пост-мортемов и не провел столько разборов инцидентов, сколько за год в Uber. Добавлю это в свой список сомнительных поводов для гордости.

Что касается самого инцидента, чем дальше я в него вгрызаюсь, тем больше хочется материться. Как тому чуваку, который устроился в контору, починил баг, который его раздражал, и уволился, мне хочется устроиться в AWS, устроиться в DevTools команду, починить CodeDeploy, и бумерангом вернуться в Uber.

Само собой, это легко звучит на бумаге и едва ли реализуемо на практике. Так что пока пинаю ТАМов, эскалирую куда могу и стою над душой.

Если мои читатели таки выполнят мою просьбу и дожмут количество 🔥до заветной суммы (см. пост по ссылке), я расскажу с максимальными подробностями, что произошло.

Предвосхищая комментарии “А что, просто так нельзя?”, отвечу - я заводил этот канал в первую очередь с ориентацией на небольшое, но активное и заинтересованное количество людей. Писать для эрудитов, тянущихся к знаниям - сплошное удовольствие. Писать для тех, кому лень даже эмодзи поставить - себя не уважать.

#машины_разное

Яндекс открыл исходный код YDB, став на моей памяти первой именитой технической компанией, открывшей код своей системы хранения данных.

Я поздравляю команду Яндекса за очередной шаг, повышающий доверие инженерного сообщества и дающий возможность людям посмотреть, что за херню вы там написали предоставить обратную связь!

UPD1: В комментариях напомнили про Clickhouse, так что Яндекс сделал это дважды.

UPD2: Tarantool был раньше. :]

#машины_разное #люди

Брендан Грегг покинул Netflix. Мы пока не знаем, куда именно, но одно известно: он продолжит работать с клавдиями, что безусловно подливает интриги в котел спекуляций.

За время работы в Sun, Грегг покричав на серверы, разработал DTrace, его опыт в Netflix подарил нам Systems Performance, flame graph'ы, много интересного контента и BPF Performance Tools.

Мне очень интересно, чем он будет заниматься впредь, и зная его по его творчеству, я смею полагать, что он не выходит на пенсию в уютное кресло СТО в очередном стартапе.

#машины_aws

Изначально я хотел сделать из этого тред в Твиттере, но там вместо этого решили накидать мне обвинений в поддержке фашистов (если вы не в теме, то я вам завидую). Ну да ладно.

Если это сообщение наберет 500 🔥, я расскажу вам адовую историю о том, как недокументированное поведение CodeDeploy после успешного развертывания привело к уничтожению нашего промышленного кластера и отказу систем и как я потом добивался от техподдержки здравого смысла.

Обещаю лонгрид на русском (Хабр) и английском (Медиум) с краткой выжимкой тут.

#жиза #пятничное

Давние читатели помнят мой эксперимент с частным коучингом, который завершился едва ли начавшись.

Я набрался шишок, опыта во внутреконторском наставничестве, устроился им в Яндекс.Практикум и продолжаю прокачивать себя в этом направлении.

Без лишней дотошности могу сказать, что ближайшим ко мне определением наставничества является оное из абсолютно упоротого фильма “Замысел”:

Х: Над всеми стоят Наставники. Они создадут проблему и наставят на путь ее преодоления. Передадут самые ценные знания, ничего не требуя взамен.
(спустя сцену)
У: Там были грабли.
Х: Угу, это я их подложил.
У: Но мне же больно!
Х: Ты получил шишку на лоб и опыт за плечи. Шишка пройдет, а опыт останется. Задача наставника не рассказать как избежать беды, а наставит на ее преодоление.

Не скажу, что помогал своим коллегам стрелять себе по ногам, но всякое бывало.

P.S. А фильм посмотрите, он крутой.

#машины_разное

А все заметили, что Jira прилегла? Эта новость особенно неприятно смотрится совместно с другой, а именно end of support self-hosted версий продукции Atlassian.

Понять решение Atlassian можно - сопровождать зоопарк из разных версий (многие, особенно толстые, заказчики не спешат с обновлением), железа, ОС и СУБД невероятный труд, не говоря уже о том, что масштабируется с трудом. Так что консолидация продаваемого продукта на мощностях самого поставщика осмысленна и прозрачна.

Однако причина, по которой крупные заказчики предпочитают держать ПО на своей площадке, зачастую не в том, что нет доверия к поставщику, но в том, чтобы иметь контроль и ответственность над надежностью ПО.

Безусловно, владеть надежностью - огромный труд, но владеть надежностью продукта, который на ответственности поставщика, который неделю отмазывается отписками, труд не только титанический, но и неблагодарный.

P.S. Могли бы просто конский ценник за сопровождение Atlassian Server выкатить, да и все. Теперь будем неделю слушать улюлюкание, что ваши клавды фуфло.

P.P.S. Инфраструктурщикам Atlassian сил и терпения, долгоживущие инциденты, пожалуй, самое мерзкое, что может произойти с дежурным.

#машины_aws

Моя эпопея с семейством Code* практически подошла к концу. Это был довольно интересный проект, которым я надеюсь однажды поделиться с амазонщиками либо на митапе, либо на конфе, там уж как Uber разрешит.

Добивающим фактором стала особенность поведения CodeDeploy при сине-зеленом развертывании с копированием AutoScaling Group (почитайте пост с Медиума, я там подробно по этому прохожусь). ASG, с которыми я работаю, привязаны к двум Target Group'ам Application Load Balancer'а. После релиза, я обнаружил, что новая ASG ни с одной TG не ассоциирована.

Оказалось, что это баг CodeDeploy - если группа привязана к одной TG, то все будет работать как надо. А вот если две, то ни одна цепляться не будет. CodeDeploy не поддерживает одновременно две TG на одну Deployment Group.

Решилась проблема с помощью скрипта, который в фазе AfterAllowTraffic делал работу, с которой CodeDeploy справляться был не в состоянии.

Решение подглядел у своих коллег по этой ссылке.

Теперь составляю список противных вещей в DevTools от AWS, который однажды туда отправлю. Вот, что собрал:
• Поддержка нескольких TG в CodeDeploy Deployment Group
• Ссылки в логе CodeBuild обладают подчеркиванием, но не кликабельны (привет, UX)
• Поддержка override параметров в CodePipeline во время запуска, например, разово взять исходники из другой ветки репозитория в стадии Source.

Кто активно пользуется, пишите в комментариях, что еще раздражает, чем длиннее будет список, тем лучше.

Голос нидерландов:

1. Тикток ушел из России
2. Макдак закрылся
3. Старбакс закрылся
4. Кока кола уходит
5. Наворованное чиновниками национализируют в бюджет

Если б я не знал контекст, я бы подумал, что Россия не просто встала с колен, а аж подпрыгнула

(ну сначала немного подпрыгнула. прим. ред.)

#пятничное

(прочистил голос)

6. Отмена НДС на покупку золота.

#машины_aws

Я продолжаю издеваться на Code* сервисами… Хотя скорее они надо мной.

В этой части разбираюсь с поведением CodeDeploy в Blue/Green развертываниях, а так же с тем, что не умеет CodePipeline и CDK.

Ваше прокрастинационное чтиво.