Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

Мониторинг IT-систем – это то, в чем рано или поздно (и в этом случае чем раньше, тем лучше) возникает острая необходимость для понимания того, а что, собственно, с нашей системой происходит? И зачастую такая необходимость идет рука об руку с другими вопросами, такими как: как это внедрить? Что мониторить? Как это развивать и поддерживать? Более того, на них становится все сложнее ответить с увеличением масштаба IT-системы.

В этой статье описан один из вариантов реализации решения такого мониторинга с использованием open-source продуктов на основе опыта внедрения его в промышленную эксплуатацию для потока событий в высоконагруженной IT-системе с микросервисной архитектурой. Под потоком событий подразумеваются, например, звонки в контактный центр, выпуск деталей, заказы на доставку еды или в общем запросы, поступающие на «вход» IT-системы.

После нескольких часов чтения обзоров, Боб с нетерпением нажал на кнопку перехода к оформлению заказа на галлон цельного молока, и…
Воу, что только что произошло?

Представляем вашему вниманию вторую часть перевода статьи о развертывании SSL/TLS, первую часть можете почитать тут.

2. Конфигурация

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

2.2. Используйте безопасные протоколы

Существует пять версий протоколов в SSL/TLS семейства: SSL v2, SSL v3, TLS v1.0, TLS v1.1 и TLS v1.2. Из них:
• SSL v2 является небезопасным и не должен быть использован.

Как скрыть от посторонних конфиденциальную информацию?
Самое простое – зашифровать.
В Интернет и Интранет-сетях шифрацией данных управляет протокол SSL/TLS.
Солдат спит, служба идет.
Однако иногда возникает необходимость выполнить обратное – расшифровать перехваченный трафик.
Это может потребоваться как для отладки работы приложений, так и для проверки подозрительной сетевой активности.
Или в целях изучения работы SSL/TLS (очевидные, вредоносные цели не обсуждаются).

Как и при каких условиях можно расшифровать дамп SSL/TLS трафика в Wireshark?
Попробуем разобраться.

Часть 2

Делимся переводом полезной статьи о том, как правильно развернуть SSL/TLS на вашем сайте. Сегодня — теория, вторая (практическая) часть будет после запуска.

Введение

SSL/TLS обманчиво кажется простой технологией. Он прост в развертывании, а потом он просто работает, не обеспечивая достаточного уровня безопасности. Но основная проблема заключается в том, что SSL/TLS нелегко правильно развернуть. Для того чтобы TLS обеспечивал необходимый уровень безопасности, системные администраторы и разработчики должны приложить дополнительные усилия в настройке своих серверов и в разработке приложений.

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

Предисловие

Под катом перевод оригинальной статьи, который мне необходимо было сделать для сдачи кандидатского зачёта по английскому языку в магистратуре. Мною был выбран именно этот текст, поскольку, ещё во время написания дипломной работы, я достаточно хорошо ознакомился с его содержимым. С тех пор прошёл уже где-то год, и только сейчас я решил его опубликовать. Примечательно, что за это время, решая задачи защиты IP-телефонии, мне довелось поработать как с TLS/SRTP, так и с IPsec. Надеюсь, для кого-то это будет полезным (как для меня, в своё время), или хотя бы просто интересным чтением. Пишите своё мнение по поводу этого материала.

P.S. В силу достаточно большого объёма, некоторые вещи я умышленно опустил, пропуски отмечены троеточием. Без перевода остался термин Information Assurance, я так и не встретил аналогии на русском.

Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.

Общие сведения о TLS

Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.

О чём эта статья

Долгое время я считал, что криптографические алгоритмы шифрования и хеширования, вроде AES и MD5, устроены очень сложно и написать их совсем не просто, даже имея под рукой полную документацию. Запутанные реализации этих алгоритмов на разных языках программирования только укрепляли это мнение. Но недавно у меня появилось много свободного времени и я решил разобраться в этих алгоритмах и написать их. Оказалось, что они очень просто устроены и для их реализации нужно совсем немного времени.

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

О нас

Доброго времени суток, Хабр! Мы компания «Информационный центр». Наше основное направление – информационная безопасность (она же – ИБ). В ИБ мы занимаемся практически всем: аудитом, проектированием систем защиты, аттестацией, комплаенсом, пентестами, есть свой SOC, даже с гостайной работаем. Поскольку мы базируемся во Владивостоке, изначально мы работали больше в Приморском крае и в дальневосточных регионах страны, но в последнее время география наших проектов все дальше раздвигает немыслимые нами в момент основания границы.

В первой своей статье мы хотели бы рассмотреть такую сторону ИБ, как комплаенс (англ. complience – соблюдение, соответствие). И поговорим мы о том, что нужно сделать, чтобы полностью соответствовать российскому законодательству о персональных данных.

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

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