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

Как правильно настроить межсетевой экран или 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 и причём тут управление рисками?

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

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

Мы знаем, как сложно отучиться от старых привычек и некоторые советы шокируют вас, но следуя им вы сможете разрабатывать приложения быстрее, сделать их менее сложными и в то же время более качественными.
В любом случае стоит помнить, что это всего лишь рекомендации и ваша команда не обязана им следовать. Вы можете продолжать использовать свои подходы, Symfony достаточно гибок для любых нужд и это никогда не изменится.

Под катом я выписал основные тезисы, большинство из них подробно аргументируется внутри книги, в некоторых «шокирующих» местах помимо тезиса есть небольшое объяснение.
Читать полностью »

CSS GuideLines, часть 1.Синтаксис и форматирование

Введение

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

Жили-были в двух соседних деревушках Вилларибо и Виллабаджо две команды разработчиков. И те и другие делали ревью кода, писали тесты, приводили рефакторинг, но через год разработки в Вилларибо уже выпустили релиз и вышли в продакшн, а в Виллабаджо все еще проводят рефакторинг и чинят баги. В чем же дело?

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.
Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

  1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
  2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
  3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в пол года отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.
Читать полностью »


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