Программа срп что это

maybe_s0_true

***
Может быть данные соглашения реально убыточные? Ответ есть!
» МИНЭНЕРГО РОССИИ: ИТОГИ РЕАЛИЗАЦИИ ДЕЙСТВУЮЩИХ ПРОЕКТОВ СРП В 2011 ГОДУ СВИДЕТЕЛЬСТВУЮТ ОБ ИХ ЭФФЕКТИВНОСТИ И ЗНАЧИТЕЛЬНОМ ВКЛАДЕ В РАЗВИТИЕ ЭКОНОМИКИ РФ»

1. Федоров сознательно дезИнформирует людей;
2. Заслуги Путина в сфере СРП объективно есть, но они незначительные (с одной из версий можете познакомиться здесь: http://kirschower.livejournal.com/243272.html*);
3. Положительна роль СРП или отрицательна — это долгая дискуссия экономистов, которую мы пока касаться не будем;
4. Самое главное — Проверяйте информацию, которой Вас кормят, и держитесь правды.

Источник: maybe-s0-true.livejournal.com

Как с помощью принципа единственной ответственности писать гибкий и модульный код

Урок , рисование файла для резки из пенопластаа . Станок Пенар

Если вы занимались разработкой ПО, вам наверняка знакома аббревиатура SOLID.

Это свод принципов, призванный помочь разработчикам писать чистый, хорошо структурированный и легко читаемый код. Программисты представляют себе по-разному «правильный» подход к написанию приложений — это больше зависит от их личного опыта и предпочтений. Однако идеи SOLID широко распространены среди разработчиков ПО, более того, они были интегрированы в Agile.

Подводные камни Singleton: почему самый известный шаблон проектирования нужно использовать с осторожностью

• Single Responsibility Principle (SRP) — принцип единственной ответственности. Каждый класс выполняет только свои задачи.
• Open-Closed Principle (OCP) — принцип открытости/закрытости — программные сущности (классы, модули, функции и пр.) должны быть открыты для расширения, но закрыты для модификации.
• Liskov Substitution Principle (LSP) — принцип подстановки Барбары Лисков гласит: «наследующий класс должен дополнять, а не изменять базовый».
• Interface Segregation Principle (ISP) — принцип разделения интерфейса: «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения».
• Dependency Inversion Principle (DIP) — принцип инверсии зависимостей: «абстракции не должны зависеть от деталей — детали должны зависеть от абстракций».

В данном материале мы рассмотрим SRP — принцип единственной ответственности.

5 главных ошибок при резке объемных фигур из пенопласта на поворотном столе СРП.

Немного предыстории

Роберт Мартин изначально ввёл термин в качестве составляющей своего труда «Принципы объектно-ориентированного проектирования». В основу SRP Мартина легла закономерность связности, описанная Томом Демарко и Мейлиром Пейдж-Джонсоном.

Кроме того, в разработке ПО есть два схожих понятия – инкапсуляция и сокрытие информации. SRP включает в себя также и эти два (или одно) понятия от Дэвида Парнаса, который обозначил их примерно так: «декомпозиция системы на модули не должна основываться на анализе блок-схем или потоков исполнения. Вместо этого, каждый модуль должен содержать внутри некоторое решение (design decision), предоставляя минимальное количество информации о нём своим клиентам».

Суть SRP

Суть SRP в одном предложении: «соберите всё, изменяемое по одной и той же причине, но разделите изменяемое по разным причинам».

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

«Божественный объект»

Классы обращаются к божественному объекту

Лучший способ изучить SRP — увидеть его в действии. Ниже показан пример программы на Ruby, не соответствующей принципу единственной ответственности. Код описывает поведение и атрибуты космической станции. Посмотрите на него и попробуйте определить:

• обязанности объектов, конкретизированные в классе SpaceStation ;
• виды лиц, которые могут быть заинтересованы в деятельности космической станции.

Видно, что класс SpaceStation имеет несколько «функций» или «задач»:

• работа с сенсорами;
• использование расходных материалов;
• расход топлива;
• использование подруливающих двигателей.

Субъекты не указаны в коде, но можно предположить, что это:

• научный работник, управляющий сенсорами;
• специалист по материально-техническому обеспечению;
• лицо, ответственное за запасы топлива;
• пилот.

Программа полностью не соответствует принципам SRP, но в полной мере отражает суть «Божественного объекта» — основного анти-шаблона в объектно-ориентированном программировани. При таком подходе объект хранит слишком большое количество данных и содержит много методов, поэтому его роль становится «божественной» или всеобъемлющей. Вместо того, чтобы общаться друг с другом, объекты обращаются к всеобъемлющему, а так как на нём завязан весь проект (или его большая часть), то его обслуживание усложняется, увеличивая риск поломки существующей функциональности.

Обратимся к примеру с космической станцией. Представьте, если надо добавить медицинский отсек, а из-за этого произойдут какие-нибудь проблемы с топливным. Попробуйте представить, что для того, чтобы шагнуть, вам нужно выгнуть левую руку назад, повернуть голову вправо и нагнуться. Работает? Да. Терпимо? Возможно. А если нужно бежать?

А если с вёдрами? То же самое и с проектом — он будет работать, но до определённого момента.

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

Разбивка по обязанностям

Выше были определены 4 функции станции, которые управлялись классом SpaceStation . Они и будут отправной точкой рефакторинга кода. Теперь программа чуть больше соответствует SRP.

Теперь класс SpaceStation скорее служит контейнером, внутри которого выполняются операции для подчинённых частей:

• набора сенсоров;
• системы подачи расходных материалов;
• топливного бака;
• подруливающих двигателей.

Каждая из частей принимает форму поля, задаваемого при инициализации космической станции. Для каждой переменной есть соответствующий класс:

• Sensors (сенсоры);
• SupplyHold (поставки расходных материалов);
• FuelTank (топливный бак);
• Thrusters (подруливающие двигатели).

В этой версии кода есть некоторые важные отличия от предыдущей, а именно: отдельные элементы функциональности не только инкапсулированы в собственные классы, но и организованы таким образом, чтобы быть предсказуемыми и последовательными. Идея заключается в группировке сходных по функциональности элементов, для следования принципу связности, и в изолировании данных таким образом, чтобы они были доступны только для соответствующих субъектов. Если понадобится изменить принцип работы системы поставки с хэш-структуры на массив, то это легко можно сделать, используя класс SupplyHold . Таким образом другие модули не будут затронуты. Причём класс SpaceStation даже не будет догадываться о действиях, производимых в модулях.

Заметьте, что сейчас в коде выше есть методы report_supplies и report_fuel , содержащиеся в классах SupplyHold и FuelTank . Что, если с Земли попросят изменить механизм загрузки отчётов? Придётся редактировать оба предыдущих класса. А если руководство решит изменить технологию доставки топлива и расходных материалов? Кажется, придётся повторно изменять те же классы. Похоже на нарушение SRP.

Надо бы исправить.

В последней версии программы обязанности «модулей» были разбиты на два дочерних класса FuelReporter и SupplyReporter , объединённых под родительским классом Reporter . Далее были добавлены экземплярные переменные к классу SpaceStation , чтобы запустить соответствующий Reporter . Если руководству с Земли понадобится ещё что-то изменить, то можно внести правки в подклассы, не влияя на работу объектов (классов), о которых они докладывают.

Конечно, до сих пор есть некоторая связь между разными классами. Например, SupplyReporter зависит от SupplyHold , так же зависим и FuelReporter от FuelTank . Кроме того, подруливающие двигатели тоже должны быть связаны с топливным баком. Все эти связи кажутся довольно логичными и на этом уровне уже можно изменять код одного объекта, не влияя на другой (либо влияя незначительно).

В итоге код программы стал более «модульным» и обязанности объектов ясным образом были обозначены. Вероятность «поломки» кода значительно уменьшена, а работать с ним стало приятнее, так как «божественный объект» (которым был весь код до второй редакции) был преобразован в SRP-код, если так можно выразиться.

Источник: tproger.ru

Блокировка вирусов и шифровальщиков с помощью Software Restriction Policies

21.10.2016

itpro

Групповые политики

комментариев 49

Продолжаем цикл статей о противодействии классу вирусов-шифровальщиков в корпоративной среде. В предыдущих частях мы рассмотрели настройку защиты на файловых серверах с помощью FSRM и использования теневых снимков дисков для быстрого восстановления данных после атаки. Сегодня речь пойдет о способе предотвращения запуска исполняемых файлов вирусов-шифровальщиков (в том числе обычных вирусов и троянов) на ПК пользователей.

Помимо антивируса, еще одним барьером для предотвращения запуска вредоносного ПО на компьютерах пользователей могут быть политики ограниченного использования программ. В среде Windows это могут быть технология Software Restriction Policies или AppLocker. Мы рассмотрим пример использования Software Restriction Policies для защиты от вирусов.

Software Restriction Policies (SRP) предоставляют возможность разрешать или запрещать запуск исполняемых файлов с помощью локальной или доменной групповой политики. Метод защиты от вирусов и шифровальщиков с помощью SRP предполагает запрет запуска файлов из определенных каталогов в пользовательском окружении, в которые, как правило, попадают файлы или архивы с вирусом. В подавляющем большинстве случаев файлы с вирусом, полученные из интернета или из электронный почты оказываются внутри каталога %APPDATA% профиля пользователя (в нем же находится папки %Temp% и Temporary Internet Files). В этом же каталоге хранятся распакованные временные копии архивов, когда пользователь не глядя открывает архив полученный по почте или скачанный с интернета.

При настройке SRP могут быть использованы две стратегии:

• Разрешить запуск исполняемых файлов на компьютере только из определенных папок (как правило, это каталоги %Windir% и Program Files / Program Files x86) – это самый надежный метод, но требует длительного периода отладки и выявления нужного ПО, которое не работает в такой конфигурации
• Запрет запуска исполняемых файлов из пользовательских каталогов, в которых в принципе не должно быть исполняемых файлов. Именно в этих каталогах в большинстве случаев оказываются файлы вируса при появлении на компьютере. Кроме того, у пользователя, не обладающего правами администратора, просто отсутствуют права на запись в каталоги системы кроме своих собственных. Поэтому вирус просто не сможет поместить свое тело куда-либо кроме директорий в профиле пользователя.

Мы рассмотрим создание SRP по второму варианту, как достаточно надежному и менее трудоемкому во внедрении. Итак, создадим политику, блокирующую запуск файлов по определенным путям. На локальном компьютере это можно сделать с помощью консоли gpedit.msc, если политика должна использоваться в домене, нужно в консоли Group Policy Management (gpmc.msc) создать новую политику и назначить ее на OU с компьютерами пользователей.

Примечание. Настоятельно рекомендуем перед внедрением SRP политик, протестировать их работу на группе тестовых компьютерах. В случае обнаружения легитимных программ, которые не запускаются из-за SRP, нужно добавить отдельные разрешительные правила.

В консоли редактора GPO перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings . Щелкните ПКМ по Software Restriction Policies и выберите New Software Restriction Policies.

Выберите раздел Additional Rules, и создайте новое правило New Path Rule.

Создадим правило, запрещающее запуск исполняемых файлов с расширением *.exe из каталога %AppData%. Укажите следующие параметры правила:

Аналогичным образом нужно создать запрещающие правила для путей, перечисленных в таблице. Т.к. переменные окружения и пути в Windows 2003/XP и Windows Vista/выше отличаются, в таблице указаны значения для соответствующих версий ОС. Если у вас в домене еще остались Windows 2003/XP, для них лучше создать отдельную политики и назначить ее на OU с компьютерами с использованием WMI фильтра GPO по типу ОС.

Запрет запуска exe файлов из архивов, открытых с помощью встроенного архиватора Windows %UserProfile%Local SettingsTemp*.zip*.exe %LocalAppData%Temp*.zip*.exe Запрет запуска exe файлов из каталога %temp% %Temp%*.exe %Temp%*.exe Запрет запуска exe файлов из вложенных каталогов %temp% %Temp%**.exe %Temp%**.exe Опционально. Запрет запуска exe фалов из любых каталогов в профиле пользователя .

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

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

Как правило, также следует запретить запуск других расширений потенциально опасных файлов (*.bat,*.vbs, *.js, *.wsh и т.п.), ведь вредоносный код может находиться не только в *.exe файлах. Для этого нужно изменить пути в правилах SPR , удалив вхождения *.exe. Таким образом, будет запрещен запуск всех исполняемых файлов и файлов сценариев в указанных каталогах.

Список «опасных» расширений файлов задается в параметрах политики SRP в разделе Designated File Types. Как вы видите, в нем уже есть предустановленный список расширений исполняемых файлов и скриптов. Можете добавить или удалить определенные расширения.

Осталось проверить действие политики Software Restriction Policies на клиентском компьютере. Для этого обновите политики командой gpupdate /force и попробуйте запустить исполняемый *.exe файл из любого из указанных каталогов. Должно появиться сообщение об ошибке:

Your system administrator has blocked this program. For more info, contact your system administrator.

Попытки запуска исполняемых файлов из защищенных каталогов, которые были блокированы политиками SRP можно отслеживать с помощью журнала событий Windows. Интересующие нас события находятся в разделе Application, и имеют Event ID 866, с источником SoftwareRestrictionPolicies и примерно таким текстом:

Access to C:UsersrootAppDataLocalTemp71E88B1F-3073-436E-A3D8-D577E72DA049dismhost.exe has been restricted by your Administrator by location with policy rule <31f4dcb9-d39b-4df3-b682-1b83892c6db4>placed on path C:UsersrootAppDataLocalTemp**.exe.

Совет. В том случае, если политика мешает запуску нужного доверенного приложения, можно добавить это файл в исключения политики (создав новое правило, указывающее на этот *.exe файл со значением Unrestricted).

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

Предыдущая статья Следующая статья

Источник: winitpro.ru

SRP — Политика ограниченного использования программ

Для усиления безопасности персональных компьютеров, в дополнение к антивирусу, достаточно эффективно зарекомендовала себя технология политики ограниченного использования программ (Software Restiction Policies). Однако удобство её настройки лимитировано особенностями редакций Windows.

Профессиональные и корпоративные редакции Windows, имеющие полноценный механизм конфигурирования SRP, рассчитаны на работу в доменной среде предприятий, где за безопасностью следят администраторы, и конечным пользователям не нужно вникать во многие нюансы. Домашним же пользователям часто приходится самим обеспечивать безопасность своих компьютеров, довольствуясь при этом одним из вариантов Windows Home, предустановленным при продаже. В этой редакции, к сожалению, отсутствует оснастка для редактирования политик безопасности, да и бдительные администраторы, как правило, не стоят за спиной невидимой тенью. Слепо доверяясь антивирусам и допуская массу ошибок при работе за компьютером, такие пользователи являются наиболее уязвимой группой и бездонным денежным мешком для разного рода доморощенных компьютерных самоучек, регулярно изгоняющих демонов из их компьютеров.
В этой статье я не буду рассматривать надежность тех или иных антивирусов, поскольку уже много лет не пользуюсь ими на своих компьютерах. Вместо этого предлагаю готовое решение для включения политики ограниченного использования программ в домашних (и не только) редакциях Windows. Кто уже утомился читать, крутите страницу до конца, и качайте архив с установочными файлами, а для желающих узнать, что включает в себя данная политика, предлагаю заглянуть под достаточно длинный спойлер со списком путей, расширений и имён файлов, запуск которых будет заблокирован на компьютере встроенными средствами ОС.
Spoiler

Как видно из листинга, блокируются поддельные двойные расширения популярных типов файлов независимо от их местонахождения на дисках, а так же ограничен запуск программ из профиля пользователя. И да, обеспокоенный безопасностью пользователь, обязательно должен работать под ограниченной учётной записью, это не обсуждается. Только в этом случае ни один вирус не скопирует себя в системные директории и не заразит весь компьютер. Самое худшее, что может произойти при работе под «Пользователем», это заражение текущего профиля, который легко пересоздаётся, но даже это потребуется вам с очень малой долей вероятности, если вы выполните рекомендации из данной статьи.

После применения политик ограниченного использования программ (пункт «Установить» в контекстном меню файла SRPPrevent.inf)

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

Если по каким-то причинам потребуется отменить ограничения SRP и привести компьютер к первоначальному незащищённому состоянию, сделать это предельно просто, достаточно деинсталлировать «Software Restiction Policy Preventing» из панели «Программы и компоненты»

.
INF-файл совместим с операционными системами от Windows Vista до Windows 10.
В архиве так же находится бинарный инсталлятор (7z SFX архив) для привычной установки двойным кликом мышью, инсталлятор имеет режим установки расширенной защиты, а так же поддержку Windows XP, подробности в файле ReadMe.txt.

Источник: jameszero.net