Рубрика «best practices» - 3

3. Check Point на максимум. Content Awareness - 1

Здравствуйте, Коллеги, добро пожаловать на третий урок курса Check Point на максимум. На этот раз мне хотелось бы обсудить блейд Content Awareness. Это относительно новая фича, которая появилась в R80.10 и многие до сих пор ее не используют, хотя весьма зря! Лично я, считаю этот блейд отличным дополнением для защиты периметра сети, но давайте обо всем по порядку.

Прежде чем начать обсуждать этот блейд, хотелось бы немного вникнуть в проблематику вопроса. Т.е. зачем нам может этот блейд в принципе пригодится. Для начала давайте рассмотрим некоторые статистические данные.Читать полностью »

в 11:22, , рубрики: api, best practices, humor

image

Как создать АПИ для умных? Такое апи, чтобы создание клиента для него было не скучным механическим процессом, а настоящим приключением с элементами детектива, хоррора и мистики? Такое апи, о котором пользователи будут взахлёб рассказываете коллегам? Апи взрывающее мозг, заставляющее смеяться, кричать и плакать? Я постарался отобрать лучшие практики, с которыми пришлось столкнуться.

Читать полностью »

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.

Так что из себя представляет стильный модный молодёжный Open Source проект в 201* году?

Читать полностью »

Как правильно настроить межсетевой экран или Check Point Security Best Practices - 1

Уверен, что у большинства системных администраторов или сетевых инженеров возникал вопрос: "Правильно ли я настроил межсетевой экран и что еще можно сделать для лучшей защиты?". Естественно, в этом вопросе стоит опираться на различные руководства (PCI DSS, ISO, NIST и т.д.) и здравый смысл. Помощь более опытных коллег также приветствуется.

В рамках же данной статьи мы попробуем описать основные рекомендации или лучшие практики (best practices) по настройке межсетевых экранов. Это некий “чек-лист”, следуя которому можно существенно повысить качество защиты сети. Руководство составлено специально для оборудования Check Point, однако оно также может быть использовано, как основа для самостоятельного аудита сети, построенной на оборудовании других вендоров (Cisco, Fortinet, Palo Alto и т.д.). Если вас это заинтересовало, то добро пожаловать под кат…
Читать полностью »

Предлагаю вашему вниманию перевод статьи What are Docker none:none images? из блога Project Atomic.

Последние несколько дней я потратил на упражнения с образами Docker <none>:<none>. Чтобы объяснить, что они собой представляют, и что могут натворить, я пишу этот пост, в котором ставлю вопросы:

  1. Что собой представляют образы Docker <none>:<none> ?
  2. Что собой представляют обособленные (dangling) образы ?
  3. Почему я вижу кучу образов <none>:<none>, когда делаю docker images -a ?
  4. В чем разница между docker images и docker images -a ?

Прежде чем я начну отвечать на вопросы, запомните, что есть два вида образов <none>:<none>: хорошие и плохие.Читать полностью »

в 16:21, , рубрики: best practices, Rust

Одной из первых вещей, которые я написал на Rust'е была структура с &str полем. Как вы понимаете, анализатор заимствований не позволял мне сделать множество вещей с ней и сильно ограничивал выразительность моих API. Эта статья нацелена на демонстрацию проблем, возникающих при хранении сырых &str ссылок в полях структур и путей их решения. В процессе я собираюсь показать некоторое промежуточное API, которое увеличивает удобство пользования такими структурами, но при этом снижает эффективность генерируемого кода. В конце я хочу предоставить реализацию, которая будет одновременно и выразительной и высокоэффективной.

Читать полностью »

КДПВ

Это перевод статьи блоггера Brian McKenna. Разрешение на перевод получено.

Прямо сейчас в сообществе DynamoDB собираются мнения. Должны ли вы писать код на 45-й строке или нет. Я твёрдо убеждён, что 45-я строка должна быть оставлена пустой. И вот почему.

45-я строка ниже края экрана

По умолчанию высота терминала — 24 строки. Если писать код на 45-й строке, то программисты не сразу заметят его. Если оставить 45-ю строку пустой, то программист ничего не пропустит. Код чаще читается, чем пишется, поэтому убедитесь, что он виден.Читать полностью »

ИБ по американски. Часть 4. Разбираемся с «подгонкой» и «перекрытиями» и завершаем этот обзор
*Оставьте свою работу на рабочем месте!*

Итак, нелёгкий путь по обзиранию созданию краткого обзора NIST SP 800-53 подходит к логическому концу. Я рад, что мне удалось совершить задуманное и написать пусть небольшой, но законченный по содержанию цикл статей, не остановившись на первой или второй части. В дальнейшем, надеюсь, получится от случая к случаю делиться с общественностью своими соображениями на тему ИБ, ИТ и аудита.

Итак, в этой статье будет наконец-то поведано о выборе набора контролей безопасности, подгонке его под нужды конкретной организации и создании так называемых перекрытий «overlays», применимых вне масштабов отдельной организации.

Ссылки на предыдущие статьи:

ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?
ИБ по-американски. Часть 3. Что из себя представляет базовый набор контролей безопасности и как определять критичность информационных систем?

Читать полностью »

image
Привет, username
Хотел написать большую статью про биологию восприятия цвета, но решил для начала ограничиться простыми правилами для начинающего/продолжающего дизайнера интерфейсов. К сожалению, грамотная работа с цветом присутствует даже не во всех продуктах крупных компаний, поэтому данный текст имеет цель не только обучить новичков, но и напомнить более опытным дизайнерам обо всех тонкостях этого вопроса.

Читать полностью »

ИБ по американски. Часть 3. Что из себя представляет базовый набор контролей и как определять критичность систем?
*Безопасность — это отнюдь не борьба с ветряными мельницами*

В предыдущих статьях я уже достаточно подробно рассказал о публикации NIST SP 800-53. Были успешно освещены разбиение контролей на семейства, подробное описание структуры контролей безопасности, процесс управления рисками в масштабах организации и даже вкратце отдельная публикация FIPS 200.
Из-за выхода в свет Geektimes пришлось немного задержаться, но мы продолжаем двигаться дальше, и сегодня речь пойдёт о базовых наборах контролей безопасности и об определении критичности информационных систем.
Ну и конечно в комплекте аутентичные американские плакаты, посвященные безопасности.

Ссылки на предыдущие статьи:
ИБ по-американски. Часть 1. Что такое NIST 800-53 и как выглядят контроли безопасности?
ИБ по-американски. Часть 2. А можно поподробнее о NIST 800-53 и причём тут управление рисками?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js