Уаософд что это – Автоматизация финансово-хозяйственной деятельности в школах: региональный опыт

Содержание

Автоматизация финансово-хозяйственной деятельности в школах: региональный опыт

В соответствии с п. 3 ч. 3 ст. 28 Федерального закона от 29.12.2012 № 273-ФЗ «Об образовании в Российской Федерации» образовательная организация должна предоставлять учредителю и общественности ежегодный отчет о поступлении и расходовании финансовых и материальных средств. В связи с этим остро встает вопрос автоматизации финансово-хозяйственной деятельности бюджетных учреждений.

Сегодня в нашей стране используется около десятка учетных систем для ведения бухгалтерского и кадрового учета и автоматизации в школе: 1С в школах, Парус, МСС, Аверс, Эпсилон и др. Как правило, в разных учреждениях одного субъекта используются разные системы для автоматизации в школе. Отсутствие технической унификации ведет к невозможности обеспечить оперативный доступ учредителя к управленческим данным, а также к неэффективному расходованию бюджетных средств на содержание этих систем.

Организация административно-хозяйственной деятельности

Подробнее по телефону 8 (800) 551-01-35

УАОСОФД для автоматизации финансово-хозяйственной деятельности учреждений г. Москвы

С целью решения этой проблемы Департамент образования города Москвы разработал план мероприятий по автоматизации финансово-хозяйственной деятельности подведомственных учреждений. Данный план предусматривает внедрение во всех учреждениях города универсальной автоматизированной облачной системы обеспечения финансово-хозяйственной деятельности (далее – УАОСОФД).

В результате его реализации:

 1) повысится качество ведения финансово-хозяйственной деятельности на местах;

2) будут сформированы единые подходы к ведению бухгалтерского учета и сдачи отчетности;

3) произойдет интеграция бухгалтерского учета и отчетности учреждений с общегородскими информационными системами: Региональной системой межведомственного электронного взаимодействия (РСМЭВ), Городской информационной системой регистрации начислений и платежей (ИС РНиП), Единой системой ведения и управления реестрами, регистрами, справочниками и классификаторами (АС УР) и др.

Заключение договора об использовании УАОСОФД

Государственным заказчиком работ по автоматизации финансово-хозяйственной деятельности учреждений средствами УАОСОФД является Департамент информационных технологий города Москвы, функциональным заказчиком – Департамент образования города Москвы, исполнителем по государственному контракту – фирма «1С».

УАОСОФД позволяет повысить прозрачность финансово- хозяйственной деятельности подведомственных учреждений, обеспечить внедрение новых инструментов управления с учетом требований информационной безопасности, провести автоматизацию в школе с учетом всех спецификаций.

Внедрение новой системы автоматизации в школах города осуществляют официальные партнеры фирмы «1С» – именно с ними учреждения должны заключать договоры. Список партнеров, которые выполняют автоматизацию в школе можно запросить в самой фирме. В случае если образовательное учреждение принимает решение передать ведение бухгалтерского и налогового учета на аутсорсинг, заключается соответствующий договор на оказание услуг по бухгалтерскому и налоговому учету. При этом желательно, чтобы компания-аутсорсер работала на базе программных продуктов 1С (это условие лучше изначально включить в договор при автоматизации в школе), а сотрудники провайдера изначально имели сертификаты по работе с УАОСОФД.

Порядок внедрения УАОСОФД

Основную работу по внедрению УАОСОФД в деятельность образовательного учреждения осуществляет партнер фирмы «1С – компания-субподрядчик. Она, в частности, осуществляет перенос в систему массивов данных, сформированных по результатам ведения бухгалтерского учета в образовательном учреждении.

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

Между фирмой «1С» и Департаментом образования города Москвы заключено соглашение о нераспространении информации о персональных данных работников образовательных учреждений. Такие же соглашения фирма «1С» заключила с официальными партнерами.

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

Далее субподрядчик автоматизации в школе формирует заявку на обучение пользователей. Время занятий предварительно согласовывается с работниками. Обучение проходит в течение трех дней. На третий день проводится тестирование работников на знание системы УАОСОФД. В случае успешного прохождения теста работнику выдается сертификат и код доступа к системе. После завершения всех необходимых процедур руководитель образовательного учреждения должен подписать акт внедрения УАОСОФД в финансово-хозяйственную деятельность учреждения и таким образом завершить бухгалтерскую автоматизацию в школе.

www.menobr.ru

Автоматизация финансово-хозяйственной деятельности учреждений: региональный опыт

Современные тенденции в области ИТ и передовые технологии направлены на развитие единых систем и консолидированной отчетности, создание централизованной инфраструктуры (ЦОД) и удаленной обработки данных, формирование сетей и защищенных каналов передачи данных.

Современные тенденции в области ИТ и передовые технологии направлены на развитие единых систем и консолидированной отчетности, создание централизованной инфраструктуры (ЦОД) и удаленной обработки данных, формирование сетей и защищенных каналов передачи данных.

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

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

· Обеспечить прозрачность своей финансово-хозяйственной деятельности в глазах учредителя и перед контролирующими органами.

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

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

В соответствии с п3 ч. 3 ст. 28 ФЗ " Об образовании в РФ" образовательная организация должна предоставлять учредителю и общественности ежегодные отчеты о поступлении и расходовании финансовых и материальных средств, соответственно учредитель заинтересован в:

· Повышении прозрачности ФХД подведомственных учреждений (возможность получать необходимые управленческие данные без дополнительных трудозатрат на уровне учреждения или округа).

· Обеспечении нового качества инструментов управления с учетом требований информационной безопасности.

Вопрос автоматизации финансово-хозяйственной деятельности бюджетных учреждений стоит довольно остро. В настоящий момент используется около десятка различных учетных систем для ведения бухгалтерского и кадрового учета (1С, Парус, МСС, Аверс, Эпсилон и т.д.). Учетные системы распределены по учреждениям, разнородны и развиваются независимо. Структуры сопровождения учетных систем не управляемы централизованно. Отсутствие технической унификации ведет к невозможности обеспечить оперативный доступ к управленческим данным, так как все они хранятся в разных системах и в разных разрезах, а также к неэффективному расходованию бюджета на содержание этих систем.

В поисках оптимального пути решения данной проблематики Департамент образования г. Москвы (ДОгМ) запустил план мероприятий по автоматизации финансово-хозяйственной деятельности (ФХД) подведомственных учреждений. (Распоряжение № 115 р от 30 мая 2014 г. (скачать, 27 Мб)  «О мерах по автоматизации финансово-хозяйственной деятельности государственных образовательных организаций и иных учреждений, подведомственных Департаменту образования города Москвы»)

План мероприятий по автоматизации ФХД государственных учреждений предусматривает внедрение УАСОФД (Универсальная Автоматизированная облачная система обеспечения финансово-хозяйственной деятельности) во всех учреждениях, подведомственных ДОгМ. Целями реализации плана являются повышение качества ведения ФХД, формирование единых подходов ведения бухгалтерского учета и сдачи отчетности в организациях, а также интеграция бухгалтерского учета и отчетности учреждений с общегородскими информационными системами (РСМЭВ, ИС РНиП, АС УР, АСУ ГФ и др).

Руководители образовательных учреждений, ровно как и конечные пользователи все чаще задаются вопросами что же такое УАСОФД, на каких условиях учреждение будет подключаться к данной системе, как происходит обучение пользователей, кто обеспечивает достоверность переноса данных и пр. В данной статье мы решили ответить на эти и многие другие вопросы, связанные с внедрением УАСОФД в образовательных учреждениях г. Москвы.

С кем заключать договор образовательной организации?

Государственным заказчиком работ по автоматизации ФХД учреждений средствами УАСОФД является Департамент информационных технологий г. Москвы (ДИТ), функциональным Заказчиком – ДОгМ. Исполнителем по государственному контракту является «Фирма «1С». Официальные партнеры 1С осуществляют внедрение новой системы в образовательных учреждениях. Поэтому образовательной организации стоит заключать контракт с компанией субподрядчиком (организация – партнер «Фирмы «1C»). В случае, если образовательное учреждение принимает решение передать ведение бухгалтерского и налогового учета в зону ответственности компании – аутсорсера – заключается соответствующий договор на оказание услуг по бухгалтерскому и налоговому учету. 

Закон от 6 декабря 2011 г. № 402-ФЗ «О бухгалтерском учете» позволяет руководителю организации заключить договор об оказании услуг по ведению бухгалтерского учета с внешней специализированной организацией. При этом стоит учитывать тот факт, что менее проблематичным будет, если компания-аутсорсер оказывает услуги на базе программных продуктов 1С, и это изначально должно быть включено в договор.

На каких условиях осуществляется подключение образовательной организации к УАСОФД?

Внедрение осуществляется компанией субподрядчиком (организация – партнер «Фирмы «1C»). Список официальных субподрядчиков можно запросить в «Фирме «1C». Субподрядчик формирует и предоставляет отчётность о ходе работ и отвечает за достижение результатов внедрения в конкретных объектах. При этом руководитель учреждения отвечает за организацию внедрения в образовательном учреждении:

· предоставляет списки пользователей – сотрудников учреждения (или ответственных сотрудников компании-аутсорсера в случае если функция ведения бухгалтерского учета в учреждении осуществляется специализированной организацией, а не силами внутренней бухгалтерской службы)

· организует участие профильных специалистов образовательного учреждения в проекте

· подписывает акты внедрения

Ответственные сотрудники компании – аутсорсера также в обязательном порядке проходят обучение по системе УАСОФД. После успешно пройденного тестирования на знание программы ответственные сотрудники подключаются к УАСОФД.

Кто и на каких условиях осуществляет перенос массивов данных, сформированных по результатам ведения бухгалтерского учета в образовательной организации в УАСОФД?

Перенос данных осуществляет субподрядчик, организация - партнер «Фирмы «1C»

Кто обеспечивает достоверность переноса данных?

Достоверность переноса данных обеспечивает компания субподрядчик совместно с ответственным лицом за ведение бухгалтерского и налогового учета в учреждении. Существует методика переноса данных. Специалист внедрения должен проверить ведение учета в программе образовательного учреждения (разработаны специальные средства проверки данных). В случае если в результате проверки выявлены замечания, ответственному сотруднику за ведение бухгалтерского учета в учреждении необходимо их исправить. После исправления всех замечаний база передается на конвертацию в систему УАОСОФД, после переноса данных в новую систему формируются утвержденные в методике необходимые отчеты за период переноса данных, которая сверяется с первоисточником.

На каких условиях осуществляется обучение пользователей работе с УАСОФД?

Руководитель образовательного учреждения формирует списки пользователей – сотрудников учреждения (или ответственных сотрудников компании-аутсорсера в случае если функция ведения бухгалтерского учета в учреждение осуществляется специализированной организацией, а не силами внутренней бухгалтерской службы). Компания субподрядчик, которая осуществляет перенос данных в систему УАСОФД, формирует заявку на обучение пользователей. Время обучения предварительно согласовывается с сотрудниками учреждения. Обучение проходит в течение 3 дней. На 3 день проводится тестирование сотрудников на знание системы УАСОФД, после успешного тестирования сотруднику выдается сертификат и доступ к системе УАСОФД.

Кто обеспечивает сохранность данных (резервное копирование, восстановление в случаях разрушения) бухгалтерского учета, персональных данных сотрудников (расчет заработной платы) образовательной организации в УАСОФД?

В рамках проекта по внедрению УАСОФД техподдержка не предусмотрена.

Кто обеспечивает разграничение доступа и нераспространение персональных данных сотрудников образовательной организации при их размещении в УАСОФД?

Между Фирмой 1С и ДОгМ заключено соглашение о нераспространение информации о персональных данных сотрудников образовательной организации, в свою очередь 1С заключила аналогичные соглашения с компаниями – партнерами.

Кто будет нести ответственность за нарушение требований по обработке персональных данных, установленных Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных», в случае предоставления доступа к персональным данным сотрудников образовательной организации, сторонней организации (не компания - аутсорсер) при переносе и размещении данных в УАСОФД?

Ответственность несут стороны, которые заключили соглашение о нераспространении персональных данных.

www.menobr.ru

Средства ГоcСОПКА. Переводим терминологию / Ростелеком-Солар corporate blog / Habr

Если вы работаете в компании, которая попадает под действие №187-ФЗ («О безопасности критической информационной инфраструктуры Российской Федерации»), то вам не нужно объяснять, что такое ГосСОПКА и зачем она нужна. Для остальных поясним: ГосСОПКА расшифровывается как Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Архитектурно она представляет собой единый территориально распределенный комплекс центров различного масштаба, обменивающихся информацией о кибератаках. Такие центры обязаны создать все компании, которым принадлежат объекты критической информационной инфраструктуры (такие компании называют субъектами КИИ). Цель всей этой масштабной государственной инициативы – создать между важнейшими организациями страны систему обмена информацией о ведущихся кибератаках и тем самым обеспечить возможность превентивной защиты.

Достаточно долгое время основным документом, определяющим принципы функционирования центров ГосСОПКА и их взаимодействия с вышестоящим центром, были «Методические рекомендации по созданию и эксплуатации центров ГосСОПКА», разработанные ФСБ. Мы ранее делали обзор данного документа и отмечали, что основным фокусом его внимания было построение процессов по управлению инцидентами и контролю защищенности субъектов ГосСОПКА. Но в то же время этот подход оставлял достаточно большое поле для различного толкования того, какой объем задач должен решать центр ГосСОПКА и какие именно инструменты для этого требуются. Недавно вышли «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты». Попробуем разобраться, чего же ждет регулятор от компаний, строящих у себя центры ГосСОПКА, и исследовать этот вопрос.


Иерархия взаимодействия центров ГосСОПКА

Известны попытки построения центров ГосСОПКА исключительно на IDS-системах. Встречаются на рынке и вендоры, позиционирующие IDS или СОА как универсальное решение проблемы. У субъектов КИИ было много вопросов было относительно функционала и требований к SIEM-системам, которые многие компкании считали чуть ли не единственным инструментом, необходимым для создания центра ГосСОПКА.

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

В документе обозначены пять основных подсистем центра ГосСОПКА:

  1. Средства обнаружения
  2. Средства предупреждения
  3. Средства ликвидации
  4. Средства расшифровки (ППКА)
  5. Средства обмена информацией
  6. Средства криптографической защиты каналов связи

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

Средства обнаружения, но не СОА. Четыре буквы


На наш взгляд, данный пункт является одним из наиболее важных с точки зрения урегулирования споров о средствах, которые можно использовать, поскольку дискуссии «а нужен ли SIEM, или достаточно просто подсистемы СОА» ведутся постоянно и не утихают.

Давайте же подробнее вчитаемся в документ:

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

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

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

Это достаточно полно следует вышедшим ранее методическим рекомендациям, ведь для того, чтобы в полной мере выявлять компьютерные инциденты категорий «несанкционированный доступ», «подбор пароля» и «ВПО», одного активного средства защиты будет недостаточно.

Любая ли платформа, позиционируемая на рынке как SIEM, будет одинаково подходящей? На наш взгляд, нет, так как в тексте обозначены еще, как минимум, два достаточно важных требования:

  • Система обнаружения должна не только коррелировать и выявлять инциденты, но и сохранять итоги их обработки и «информацию об событиях ИБ, в том числе в исходном виде». Учитывая обозначенный выше список источников, а еще и рекомендуемую глубину хранения (не менее 6 месяцев), речь идет о полноценной платформе с расширенным функционалом Log Management и готовностью обрабатывать очень существенные потоки событий. Это достаточно сильно сокращает список потенциальных вариантов.
  • Система обнаружения должна иметь «встроенную поддержку различных источников событий ИБ и возможность разработки дополнительных модулей, обеспечивающих получение информации от новых источников событий ИБ», то есть возможность оперативной доработки списка и состава подключаемых источников. Это накладывает требования по наличию открытого API для разработки таких способов подключения (в SIEM-сленге – коннекторов) либо возможности оперативно получить такую доработку от вендора.

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

Предупреждай или инвентаризируй это


Следующий раздел — средства предупреждения — значительно ближе и понятнее для безопасника и формулировками, и подходами. На средства предупреждения возлагаются следующие функции:
  • Инвентаризация активов инфраструктуры с возможностью хранения и дополнения информации.
  • Сбор и оценка информации об уязвимостях информационных ресурсов.
  • Сбор и оценка информации о недостатках (в нашем прочтении – ошибках конфигурирования) информационных ресурсов.

Описанный перечень функций чаще всего реализуется программными продуктами класса Vulnerability Scanner или сканеры защищенности. Казалось бы, неочевидное название «система предупреждения» несет в себе очень правильную логику: невозможно предупредить потенциальный вектор развития атаки и выявить слабые точки инфраструктуры, если ты не владеешь полной информацией об ее состоянии, используемых узлах, программных или процессных уязвимостях своих активов.

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

Ликвидация как совместная работа по устранению


Здесь и название средства, и требования к нему получили достаточно неожиданную интерпретацию. В качестве средства ликвидации мы решение, по функциональным задачам близкое к к платформе управления инцидентами, которая в ИТ-мире носит название service desk, а в ИБ горделиво именуется Incident Response Platform (правда у IRP есть и специализированный функционал). По сути, основные задачи подсистемы — это:
  • Регистрация инцидентов с возможностью редактирования и дополнения карточки инцидента.
  • Возможность управления его жизненным циклом с переводом инцидента между ответственными и подразделениями.
  • Возможность сбора итоговой карточки инцидента согласно форматам, утвержденным в НКЦКИ.

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

Выбор решений и технологий, созданных специально для задач ИБ, на рынке еще весьма ограничен. Но в документе нет прямых ограничений на использование для этих целей общей IT системы (в стандартном или индивидуальном исполнении) с некоторыми доработками под задачи ИБ. Обычно системы service desk представляют собой хорошо кастомизируемый конструктор, поэтому доработка не должна составить труда.

Прочие средства центра ГосСОПКА


Функционал и задачи подсистемы ППКА в первую очередь направлены на анализ сетевого трафика, причем как в real-time режиме (с целью выявления атак или попыток несанкционированного доступа к сетевому оборудованию), так и для записи и хранения сетевого трафика с целью его дальнейшего использования в ретроспективном анализе событий или расследовании инцидента. Данные требования не являются принципиально новыми. Задача записи сетевого трафика ставилась перед всеми владельцами государственных информационных систем еще с 2010 года в рамках совместного приказа ФСТЭК и ФСБ. Эти требования могут быть неожиданными для коммерческих компаний, но фактически их реализация также не несет особых сложностей.

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

В качестве короткого резюме – выход данного документа расставил очень много точек над I в отношении инструментов и технологий, которыми необходимо оснащать центр ГосСОПКА. Теперь у каждого заказчика есть формальный список требований, который пригодится как для сравнения вендоров, так и для принятия решения об покупке/замене технологии. А появление ясности в таких вопросах всегда положительно влияет на эффективность и скорость шагов, предпринимаемых конкретными субъектами для подключения, равно как и на общую защищенность критических информационных инфраструктур.

habr.com

что это, для кого, и как оплачивается / ИТ-ГРАД corporate blog / Habr

Облачные сервисы за последние несколько лет проникли во многие сферы жизни и бизнеса — в результате появилось много разновидностей подобных ресурсов и соответствующих аббревиатур (SaaS, PaaS, IaaS).

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

В сегодняшнем материале мы рассмотрим весь стек облачных технологий и подробнее остановимся на одной его части — корпоративном IaaS.

Как пицца, только облако


Стек облачных технологий состоит из трех частей, каждая из которых представляет отдельную категорию сервисов:
  • SaaS — приложения, работающие в облаке, доступ к которым конечные пользователи получают через веб.
  • PaaS — набор инструментов и сервисов, облегчающих разработку и развертывание облачных приложений.
  • IaaS — вычислительная инфраструктура (серверы, хранилища данных, сети, операционные системы), которая предоставляется клиентам для разворачивания и запуска собственных программных решений.

Описанную схему можно изобразить в виде диаграммы:

Наглядно различия между ключевыми видами облачных услуг можно проиллюстрировать с помощью концепта “Pizza as a Service” — в нем «облака» сравниваются с пиццей. Если потребитель хочет прийти в ресторан и заказать пиццу там — это SaaS, если он оплачивает доставку на дом, то это PaaS, а если покупает ингредиенты в магазине и сам готовит себе пиццу — аналогия с IaaS:

Сегодня мы подробнее рассмотрим как раз этот последний вариант.

Что такое IaaS


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

Существует несколько подкатегорий IaaS — получение услуг может осуществляться с помощью публичного или частного облака, а также комбинации этих подходов («гибридное облако» — о создании такого облака с помощью VMware vCloud Connector мы писали отдельный материал на Хабре).

Характеристики и провайдеры IaaS


Понятие инфраструктуры как услуги включает в себя несколько основных характеристик:
  • Ресурсы распространяются в качестве услуги.
  • Существует возможность динамического расширения (и сокращения) объёмов потребляемых ресурсов.
  • Реализованы гибкие модели оплаты (например, оплата только за фактически потребленные ресурсы — модель pay as you go).
  • Как правило, с одним физическим «железным» ресурсом работают несколько пользователей.

В мире существует огромное количество провайдеров IaaS — среди самых известных, к примеру, Amazon Web Services, помимо этого на региональных рынках присутствуют свои сильные игроки. На Хабре был интересный материал с обзором российских провайдеров IaaS-услуг.


Когда стоит использовать IaaS


В том случае, если у специалистов конкретной компании есть опыт создания и администрирования ИТ-инфраструктуры, в определенных условиях использование IaaS будет оптимальным вариантом. Вот несколько наиболее распространенных случаев:
  • Потребность компании в ИТ-ресурсах не одинакова в разные моменты времени — бывают сильные всплески, когда потребности вырастают, но они не длятся долго.
  • Компания — это стартап, у которого просто нет денег на покупку железа и создания собственной инфраструктуры.
  • Организация быстро растет, и возникает проблема постоянного масштабирования инфраструктуры.
  • Существует потребность в снижении операционных издержек, в том числе на оборудование.
  • При запуске нового экспериментального направления бизнеса, которое нужно протестировать или которое не требует постоянного выделения ИТ-ресурсов.

Когда не стоит использовать IaaS


Несмотря на гибкость и масштабируемость IaaS, у этой технологии есть определенные ограничения, и существуют ситуации, когда ее использование проблематично:
  • Если компания является игроком регулируемой отрасли, правила которой не разрешают хранение данных на серверах, не принадлежащих компании (и часто находящихся в другой стране).
  • IaaS может не подойти тем компаниям, которым требуется высочайший уровень производительности — его проще достигнуть с помощью использования выделенных инфраструктурных ресурсов (hosted infrstructure).

Как за все это платить


В том случае, если в аренду берется инфраструктура по модели IaaS, то как правило, существуют два варианта тарификации:
  • Первый из них подразумевает продажу общих (shared) ресурсов провайдера, которые ограничиваются общей производительностью сервера. В таком случае ресурсы можно докупать по мере надобности (и так же по мере надобности от них отказываться), и оплачивать только потребленные мощности — это модель Pay as you go.
  • Второй вариант — использование гарантированно выделенных ресурсов (Reservation Pool). Эта схема подразумевает резервирование фиксированного объёма ресурсов, которые компания-клиент использует и оплачивает ежемесячно по фиксированному же тарифу.

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

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

Заключение


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

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

Спасибо за внимание. Не забывайте подписываться на наш блог!

habr.com

Что такое ОБСЕ и чем занимается эта организация? | Справка | Вопрос-Ответ

ОБСЕ (от англ. OSCE — Organization for Security and Co-operation in Europe, фр. Organisation pour la sécurité et la coopération en Europe) — Организация по безопасности и сотрудничеству в Европе. Крупнейшая в мире региональная организация, занимающаяся вопросами безопасности. Она объединяет 57 стран, расположенных в Северной Америке, Европе и Центральной Азии.

ОБСЕ создана 1 августа 1975 года в Хельсинки, Финляндия, где главы 35 государств в тот день подписали Заключительный акт Совещания по безопасности и сотрудничеству в Европе (Хельсинкские соглашения).

Цели и задачи ОБСЕ

Главная цель ОБСЕ — предотвращение возникновения конфликтов в регионе, урегулирование кризисных ситуаций, ликвидация последствий конфликтов.

Основные средства обеспечения безопасности и решения основных задач организации:

1) «Первая корзина», или политико-военное измерение:

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

2) «Вторая корзина», или экономическое и экологическое измерение:

  • экономическая и экологическая безопасность.

3) «Третья корзина», или человеческое измерение:

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

Все государства-участники ОБСЕ обладают равным статусом. Решения принимаются на основе консенсуса. Они не носят юридически обязательного характера, но имеют большое политическое значение.

Штат организации — около 370 человек, занятых в руководящих органах организации, а также около 3500 сотрудников, работающих в полевых миссиях.

Участники ОБСЕ

  • Австрия
  • Мальта
  • Азербайджан
  • Молдавия
  • Албания
  • Монако
  • Андорра
  • Монголия
  • Армения
  • Нидерланды
  • Белоруссия
  • Норвегия
  • Бельгия
  • Польша
  • Болгария
  • Португалия
  • Босния и Герцеговина
  • Россия
  • Ватикан
  • Румыния
  • Великобритания
  • Сан-Марино
  • Венгрия
  • Сербия
  • Германия
  • Словакия
  • Греция
  • Словения
  • Грузия
  • США
  • Дания
  • Таджикистан
  • Ирландия
  • Туркмения
  • Исландия
  • Турция
  • Испания
  • Узбекистан
  • Италия
  • Украина
  • Казахстан
  • Финляндия
  • Канада
  • Франция
  • Кипр
  • Хорватия
  • Киргизия
  • Черногория
  • Латвия
  • Чехия
  • Литва
  • Швейцария
  • Лихтенштейн
  • Швеция
  • Люксембург
  • Эстония
  • Македония

Партнёры ОБСЕ

  • Алжир
  • Афганистан
  • Египет
  • Израиль
  • Южная Корея
  • Иордания
  • Таиланд
  • Марокко
  • Япония
  • Тунис
  • Австралия

Структура ОБСЕ

Основными органами организации являются:

  • Саммит (встреча на высшем уровне) — периодически проводимая встреча глав государств и правительств стран ОБСЕ.
  • Совет министров иностранных дел — ежегодная (кроме года встреч на высшем уровне) встреча министров иностранных дел государств-участниц ОБСЕ.
  • Постоянный совет под руководством действующего председателя (англ. Chairperson-in-Office, CiO), занимающего этот пост в течение года. Проводит на регулярной основе политические консультации и принимает решения (еженедельно собирается в Вене).
  • Форум по сотрудничеству в области безопасности — регулярно обсуждает вопросы контроля над вооружениями и МДБ (еженедельно собирается в Вене).
  • Верховный комиссар по делам национальных меньшинств.
  • Бюро по демократическим институтам и правам человека ОБСЕ.
  • Парламентская ассамблея ОБСЕ.
  • Представитель по вопросам свободы СМИ — наблюдает за развитием положения в области средств массовой информации в 56 государствах-участниках ОБСЕ.

Официальные языки ОБСЕ

Официальными языками Организации по безопасности и сотрудничеству в Европе являются:

  • английский,
  • испанский,
  • итальянский,
  • немецкий,
  • русский,
  • французский.

Руководство ОБСЕ

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

На заседании Совета министров ОБСЕ в начале декабря 2013 года в Киеве председателем ОБСЕ в 2014 году была выбрана Швейцария во главе с действующим президентом страны Дидье Буркхальтером.

Генеральный секретарь — возглавляет секретариат. Назначается Советом министров сроком на 3 года. С 2011 года по настоящее время им является Ламберто Занниер.

Бюджет ОБСЕ

Сводный бюджет ОБСЕ состоит из двух частей: бюджет секретариата и институтов и бюджет полевых операций. В 2013 году бюджет организации составил 145 млн евро.

Специальная мониторинговая миссия ОБСЕ на Украине

Специальная мониторинговая миссия ОБСЕ на Украине (СММ) — это невооружённая гражданская миссия, основные задачи которой — беспристрастно и объективно наблюдать за ситуацией на востоке Украины и отчитываться по ней, а также способствовать диалогу между всеми сторонами конфликта. СММ начала свою работу 21 марта 2014 года в связи с обращением правительства Украины в ОБСЕ и общим решением всех стран-участниц ОБСЕ. Мандат миссии продлевается каждые полгода.

Смотрите также:

aif.ru

Как создавать безопасные системы. Краткое введение в SDL / Microsoft corporate blog / Habr

При разработке любой программной системы, будь это простой вебсайт, десктоп-приложение или сложный трехзвенный комплекс, рано или поздно возникают вопросы безопасности. Нельзя исключить, что та система, которую вы разрабатываете, будет каким-то образом атакована. Причем, в зависимости от типа системы, ее сложности, применяемых технологических решений, векторы атак и их последствия могут иметь самый разный характер. Возможно, время от времени кто-то в команде проводит анализ безопасности разрабатываемой системы, проводится моделирование. Куда хуже если эти вопросы оставляются на потом. Результаты могут быть весьма плачевными, если вашу систему взламывают в режиме коммерческой эксплуатации и вам приходится впопыхах создавать исправления для обнаруженной бреши. Очевидно, что вопросы, связанные с безопасностью лучше решать, начиная с самых ранних этапов создания системы, таких как анализ требований и архитектурного моделирования. Но лучше всего это делать на всем жизненном цикле системы, интегрировав в процесс разработки специальные шаги, предназначенные для решения этих вопросов. Одним из таких процессов является Security Development Lifecycle – набор практик направленных на повышение безопасности разрабатываемых систем.
Что такое Security Development Lifecycle

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

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

Перед тем как внедрить SDL: Обучение

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

Безопасный дизайн

  • Снижение областей атаки
  • Глубокая защита
  • Принцип наименьших привилегий
  • Безопасность по умолчанию

Моделирование угроз, включая следующие темы:

  • Обзор моделей угроз
  • Влияние модели угроз на дизайн
  • Ограничения для стиля кодирования, базирующиеся на модели угроз

Безопасное кодирование, включая следующие темы:
  • Переполнение буфера (для приложений на C и C++)
  • Ошибки целочисленной арифметики (для приложений на C и C++)
  • Кросс-сайтовый скриптинг (для Веб-приложений)
  • SQL-инъекции (для приложений взаимодействующих с БД)
  • Слабая криптография

Тестирование безопасности, включая следующие темы:
  • Различия между тестированием безопасности и функциональным тестированием
  • Аудит рисков
  • Методы тестирования безопасности

Обеспечение приватности, включая следующие темы:
  • Типы приватной информации
  • Приватность: лучшие практики дизайна
  • Аудит рисков
  • Приватность: лучшие практики разработки
  • Приватность: лучшие практики тестирования

Конечно, при изучении этих тем необходимо учитывать роль (тестер, разработчик, менеджер, аналитик), тем не менее, очень важно чтобы все члены команды прошли этот тренинг.
Анализ требований: Что следует учитывать в контексте безопасности

Уже на уровне анализа требований к системе нужно учитывать важные аспекты, связанные с безопасностью. При этом важно разделять между собой «безопасные требования» и «требования безопасности». В SDL есть некоторый набор практик, и несколько таких из таких практик – «Анализ безопасности и приватности требований» может быть применена на этапе анализа требований. Эта практика предназначена для идентификации функциональных требований, у которых есть необходимость углубленного изучения вопросов связанных с безопасностью. Такой аудит может включать в себя следующую информацию:

  1. Какая часть ПО требует анализа угроз перед релизом?
  2. Какая часть ПО требует анализа дизайна в контексте безопасности?
  3. Какая часть ПО требует дополнительного анализа угрозы проникновения независимой группой?
  4. Есть ли дополнительные вопросы безопасности и риски, которые могут быть снижены?
  5. Границы нечеткого тестирования в контексте безопасности.
  6. Каков уровень угрозы разглашения приватных данных?
Дизайн с учетом безпасности

При дизайне приложений так же можно применить ряд практик, которые помогут повысить безопасность приложения. В первую очередь это снижение площади поверхности возможных атак (Attack Surface Reduction) и моделирование угроз. Несмотря на близкую взаимосвязь этих двух понятий, первый механизм подразумевает активное снижение возможностей злоумышленника на эксплуатацию неизвестных брешей в безопасности. Для снижения площади возможных атак можно применять механизмы послойной защиты и принципы наименьших привилегий. Моделирование угроз в свою очередь позволяет предположить, какие компоненты системы могут быть рассмотрены в качестве векторов атак. Удобным инструментом для моделирования угроз является Microsoft Thread Modeling Tool базирующийся на классификации STRIDE.

Реализация с учетом безопасности

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

Фаза верификации (тестирования) с учетом безопасности

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

Фаза Выпуска с учетом безопасности

На этой фазе важно создание плана по реакции инцидентов связанных с безопасностью, в которых будет задекларирован порядок взаимодействия и реакции на выявленные угрозы или проникновение. Финальные релизы (RTM,RTW) должны соответствовать всем заранее обговоренным на стадии дизайна условиям безопасности перед развертыванием. Если это не так, даже при соблюдении всех функциональных требований, необходим повтор стандартного цикла разработки для фиксации проблем связанных с безопасностью.

Что дальше

Конечно, эта заметка раскрывает только самые основные аспекты SDL и для успешного применения требуется дополнительное изучение. Помочь в этом может центр безопасности MSDN.

Если вы хотите узнать более подробно о SDL, посмотрите завтра прямую трансляцию докладов конференции «Microsoft Secure Software Development Conference». В том числе там будут доклады Алекса Лукаса «Эволюция цикла безопасной разработки SDL», Гленна Питавея «Внедрение SDL».

habr.com

что это такое? Виды и классификация софта :: SYL.ru

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

Софт: что это такое в общем понимании?

Укороченное название софт в русском языке образовано от английского слова Soft, которое, в свою очередь, соответствует термину Software. Для понимания его значения для начала стоит просто перевести сам термин. Он означает «мягкий». Но что же такого мягкого может быть в компьютере?

софт что это такое

Тут надо вспомнить, что в компьютере может быть твердого. Это – так называемое компьютерное железо, или Hardware. То есть все установленные или подключаемые устройства, которые, если можно так выразиться, можно потрогать. Отсюда можно сделать вывод и о термине «софт». Что это такое? В общем понимании это набор программного обеспечения разного типа, за счет которого и компьютер функционирует, и человек, с ним работающий, может использовать системные или самостоятельно устанавливаемые программы.

Программы (софт): разновидности ПО

Теперь несколько слов о классификации современного программного обеспечения (Software). В самом простом варианте любой софт (программы) можно разделить на две большие категории: программы, устанавливаемые (записываемые) на жесткий диск или внутренний накопитель (для мобильных систем), и заводская прошивка (первичные системы ввода/вывода BIOS и UEFI), в которых хранится вся информация по установленным устройствам, и в момент старта системы производится тестирование их функциональности.

софт программы

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

Классификация программного обеспечения по назначению

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

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

софт для windows 7

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

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

виды софта

Прикладные программы – самый большой класс, который включается в понятие «софт». Что это такое? Да все что угодно. Тут и офисные программы, и средства доступа в интернет, и инструменты мультимедиа, и антивирусные средства защиты, и диагностические утилиты или оптимизаторы, и инженерные программы, и средства работы с архивными данными, и развлекательные приложения, и системы управления базами данных, и еще много-много всего. Просто вспомните, чем вы чаще всего пользуетесь в повседневной работе на компьютере. Практически все программы и будут относиться к прикладному ПО. Сегодня софт для Windows 7, другой версии системы или мобильной платформы настолько разнообразен, что описать все, что можно использовать, не получится просто физически.

Дополнительная классификация софта

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

Однако в таком разделении выделяют три основных группы программ:

  • бесплатные;
  • условно-бесплатные;
  • платные.

С первой и третьей категориями, думается, все понятно и так. А вот условно-бесплатное программное обеспечение (Shareware) имеет одну главную особенность: пользоваться такими приложениями без оплаты или с использованием их ограниченного функционального набора можно только в течение определенного периода (обычно 30 дней), после чего нужно будет либо приобрести полную версию программного продукта, либо ввести специальный ключ активации или лицензии, за что и придется заплатить. Если этого не сделать, приложение далее использовать будет невозможно, поскольку оно может блокироваться или просто станет полностью неработоспособным, а при попытке его запуска пользователю постоянно будет выдаваться сообщение о том, что пробный период закончился, а программу нужно купить или активировать.

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

В заключение

Вот и все, что касается основных видов софта и его классификации по разным критериям. Главный вывод, который напрашивается сам собой, состоит в том, что каждый пользователь должен понимать, что софт – это именно программное обеспечение (так называемая софтверная часть). А без некоторых его типов (операционные системы, драйверы) компьютер может не работать вообще.

www.syl.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о