Один из первых шагов к началу это составление технических заданий на разработки. Давайте рассмотрим частые проблемы которые возникают при работе на «устных задачах» (такое как правило практикуется при разработке в 1С:Предприятии) и как техническое задание позволяет их решить.

Разработки «однодневки»

Что это такое? Это разработки, которыми будут пользоваться очень редко или вообще один раз, например когда пользователи не хотят составлять разово отчет в excel и требуют его разработку, а воспользовавшись им забывают про него (в одной компании, где мне довелось работать, в 1С:Предприятии 7.7 более сотни внешних отчетов, а пользовались от силы десятком). Как техническое задание помогает в борьбе с такими разработками? Да очень просто, зачастую людям просто лень его составлять и им проще взять в руки excel (Open office Сalc) и разово составить отчет, или прсто руками провести изменение пары десятков записей в БД, и человек видя, что трудозатраты на составление технического задания много больше, чем сделать ту-же работу руками, просто делает ее руками.

Сделай то, не знаю что, сделай так, не знаю как

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

Как писать техническое задание?

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

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

Примерный план такой:

1. цель разработки и ее обоснование;
2. используемые средства;
3. описания бизнес процессов (если есть);
4. само задание с примерами входных и выходных форм.

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

Заключение

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

У нас есть таблица OUR_TABLE с колонками:

• ID:INT;
• COL1: VARCHAR(15);
• COL2: VARCHAR(15);

В ней есть две записи:

Наша задача заменить значение в первой строке в колонке COL2 на соответствующее значение из второй строки.

Решение

На вскидку нам приходит решение:

1
2
3
4

UPDATE our_table
SET
   col2 = (SELECT col2 FROM our_table WHERE id = 2)
WHERE id = 1

Но не тут-то было! MySQL выдаст вам ошибку, которую можно интерпретировать очень просто, во вложенном подзапросе не может фигурировать обновляемая таблица. Возникает вопрос, как нам быть? Ведь хочется все сделать красиво… Курение документации по MySQL подсказало решение: в синтаксисе UPDATE можно использовать соединения (JOIN), и вот оно готовое рабочее решение:

1
2
3
4
5
6
7
8
9
10

UPDATE our_table ot
LEFT JOIN (
   SELECT
       1 AS id, otj.col2
   FROM our_table otj
   WHERE otj.id = 2
) ou ON ou.id = ot.id
SET
    ot.col2 = ou.col2
WHERE ot.id = 2

Практическое применение

Как это использовать на практике? Просто, вот пример как в phpBB скопировать одну запись на место другой:

1
2
3
4
5
6
7
8
9
10
11
12

$sql = "UPDATE ".POSTS_TEXT_TABLE." ptt1
       LEFT JOIN (
            SELECT
              ".$new_topic['topic_first_post_id']." post_id,
	      ptt.bbcode_uid, ptt.post_subject, ptt.post_text
            FROM ".POSTS_TEXT_TABLE." ptt
            WHERE ptt.post_id = ".$topic['topic_first_post_id']."
       ) ptt2 ON ptt1.post_id = ptt2.post_id
       SET ptt1.bbcode_uid = ptt2.bbcode_uid,
           ptt1.post_subject = ptt2.post_subject,
           ptt1.post_text = ptt2.post_text
       WHERE ptt1.post_id = ".$new_topic['topic_first_post_id'];

Заключение

К чему такие сложности? Производительность складывается из мелочей, и одной из них является то, что мы лишний раз не передаем данные на клиента (как было сказано в одной из предыдущих моих записей) передача данных на клиента после выполнения запроса самая узкая часть в производительности.

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

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

Соберем все прямые затраты которые явно на поверхности:

Как видно из приведенных расчетов, с каждым годом совокупная стоимость владения нашим программным продуктом будет увеличиваться на сумму, как минимум, заработной платы программиста 1С, и налоги которые вы заплатите с суммы его заработной платы и будет составлять: 328 800 рублей (для упрощения будем считать, что заработная плата программиста не повышается с течением времени). Теперь мы видим, что, например, через 5 лет совокупная стоимость владения составит примерно 1,7 млн. рублей.

В наших расчетах совокупной стоимости владения четко видно, что основная масса затрат идет на оплату труда персонала который занимается сопровождением программного продукта. Давайте теперь рассмотрим как реально выглядит работа программиста 1С. Чем обычно занимается программист 1С? Наверное вы думаете, что он программирует на платформе 1С:Предприятие, а вот и нет! 90% своего рабочего времени он занимается устранением последствий некомпетентности сотрудников компании!

В свое время мной проводилась аналитика задач поступавших от бухгалтерии, так вот, статистика там была неутешительная 80% заданий составляли банальное незнание бухгалтерами программного продукта и только 20% с натяжкой можно было отнести к задачам, где требовалось вмешательство программиста (а точнее высококвалифицированного специалиста). Помимо этого, даже если программисту придется все таки заняться разработкой на платформе 1С:Предприятие, то и тут перспектива вполне может оказаться не радужной, основные задачи которые решает программист, это создание новых отчетов, и тут, по личному опыту, 90% отчетов однодневок, т.е. тех которые нужны для разового извлечения данных (например в одной компании из более чем 100 разных отчетов, написанных программистами, использовалось всего 12 отчетов). И теперь, все таки иногда, требуется вмешательство программиста для расширения функционала программного продукта, но как часто? Да изменения в конфигурации 1С:Предприятия любой версии вносятся часто, этот факт отрицать трудно, но на фоне остальных задач они занимают лишь незначительную часть рабочего времени программиста 1С.

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

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

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

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

И так, приступим. Прежде всего, схема задействованных таблиц (не пинайте за использование схем UML, в Dia просто не было подходящих картинок):

Стрелками обозначены связи между таблицами. Наша задача простая, в таблице sp_create в поле size записана строка с разделителями в которой содержатся варианты размеров для каждой записи, в таблице sp_user в поле size один из вариантов размера строкой, нам нужно:

1. все строки с разделителями считать, разложить на составляющие и записать отдельными строками в таблицу sp_rows;
2. в таблице sp_user текстовое поле size сопоставить по полям art_id и sp_row_value с таблицей sp_rows и записать соответствующий идентификатор записи.

Язык написания скрипта конвертации php 5, сервер БД MySQL, компьютер на котором проводилась конвертация ноутбук на процессоре Celeron M 1.5 GHz, 1,2 Gb RAM.

Вариант решения 1: Первый пришедший в голову

Первое, что пришло в голову это реализация вложенными циклами. Алгоритм такой:

SELECT art_id, size FROM sp_create

while {

while {

INSERT INTO sp_rows (art_id, sp_row_value) VALUES ([значения])

}

SELECT sp_row_id, sp_row_value FROM sp_rows WHERE art_id = [ранее считанный]

SELECT size FROM sp_user WHERE art_id = [ранее считанный]

while {

UPDATE sp_user SET sp_row_id = [значение]

}

}

Первый рабочий запуск на дампе боевой базы заставил меня прослезиться, конвертация длилась 8 часов! И это при том, что я выделил MySQL уже прилично оперативной памяти.

Тут закрадываются мысли об оптимизации, стоит немного объяснить их ход, читая множество обзоров в которых приводится производительность разных SQL серверов невольно приходит в голову «знание», что операции INSERT и UPDATE на порядок медленнее чем SELECT (строго говоря это так, но все таки тесты немного врут, почему, будет сказано далее) поэтому, первое, что пришло в голову, нужно оптимизировать запись в таблицы. Google подсказал такие слова как LOCK TABLES и BULK INSERT.

Вариант решения 2: Оптимизация INSERT и UPDATE

Что такое BULK INSERT? Если кратко и своими словами — это массовая запись значений одним запросом, или несколькими большими, в нашем случае, MySQL работает с ними охотнее и быстрее. LOCK TABLES — это блокировка таблиц перед записью, эффект достигается тем, что MySQL не записывает индексы до тех пор пока не будет снята блокировка. Теперь мой скрипт выглядел так:

SELECT art_id, size FROM sp_create

while {

INSERT INTO sp_rows (art_id, sp_row_value) VALUES ([значения]), ([значения]), ([значения]), ([значения])

SELECT sp_row_id, sp_row_value FROM sp_rows WHERE art_id = [ранее считанный]

SELECT size FROM sp_user WHERE art_id = [ранее считанный]

LOCK TABLES sp_user WRITE

while {

UPDATE sp_user SET sp_row_id = [значение]

}

UNLOCK TABLES

}

Ускорение на лицо, но слезы не перестают течь, конвертация идет 4 часа. Я задаюсь вопросом, что я делаю не так, и почему все так медленно работает. Наступает время смотреть а где у меня самое узкое место? Ставлю MySQL Administrator начинаю мониторинг, и что я вижу? А вижу я, что самое узкое место, это SELECT’ы, но почему? Все учебники говорят об обратном, но все забывают, что после выполнения SELECT идет передача данных клиенту, и это и есть наше «бутылочное горлышко»! Что имеем, в секунду выполняется в среднем 2500 INSERT’ов и всего(!) 5 SELECT’ов. Теперь вооружившись этой информацией, приступаю к оптимизации скрипта.

Вариант решения 2: Ускоряемся

SELECT art_id, size FROM sp_create

LOCK TABLES sp_create WRITE

while {

INSERT INTO sp_rows (art_id, sp_row_value) VALUES ([значения]), ([значения]), ([значения]), ([значения])

}

UNLOCK TABLES

SELECT sp_row_id, sp_row_value FROM sp_rows

SELECT size FROM sp_user

LOCK TABLES sp_user WRITE

while {

UPDATE sp_user SET sp_row_id = [значение]

}

UNLOCK TABLES

Ура! Вот результат работы: конвертация размеров в sp_create 30 секунд, сопоставление размеров и их запись в sp_user 18 секунд, общее время работы скрипта 48 секунд!

Выводы

Какие выводы можно сделать? Очень простые, один большой запрос лучше чем много маленьких (для примера могу сказать, что во время написания скрипта я вывел в браузер массив с выборкой из sp_rows, опера показала, что страница размером была 9,5 мегабайт), так как время передачи информации клиенту сводит на нет все преимущества по скорости выполнения SELECT, если есть возможность, объединяйте INSERT в группы, при долгих массовых вставках или изменениях ставьте блокировку таблицы оператором LOCK TABLES.

Литература

INSERT

LOCK / UNLOCK TABLES

Первое, что бросилось в глаза мне, это переизбыток ИТ специалистов, причем 90% кандидатов имеют опыт работы менее 3-х лет. Из них, примерно половина уже ищет работу по полгода и более.

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

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

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

Итак:

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

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

3. Контактные данные. Самая распространенная ошибка, это указание несерьезного адреса электронной почты, поверьте мне, адрес типа darkangel89@домен.ру или, что еще хуже, stervec@домен.ру смотрятся весьма не серьезно, тем более он указывается в самом начале. Сейчас не проблема завести себе адрес электронной почты который будет содержать вашу фамилию и имя.

Советы по составлению резюме:

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

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

Искренне желаю успехов в поисках работы, тем более в тяжелые времена мирового фининсово-полового кризиса.

В свое время 1С: Предприятие 7.7 являлось, пожалуй, самой популярной платформой для создания бизнес приложений в России. И это не удивительно, ведь благодаря наличию встроенного языка программирования, простоте, дешевизне, и открытости типовых конфигураций с ней можно было творить все, что душе угодно, чем, кстати, и занимались отделы ИТ малых, средних и крупных предприятий нашей необъятной Родины. В результате многие крупные компании получили весьма интересные и специфичные конфигурации, которые затруднили переход компаний на 1С:Предприятие восьмой версии, и многие по сей день продолжают использовать семерку. Но у 1С: Предприятия 7.7 есть и свои архитектурные проблемы. И прежде всего это отсутствие масштабируемости, при наступлении определенного числа одновременно работающих пользователей, в результате конструктивных просчетов, наступает состояние когда люди не могут провести или записать документы, а в ответ получают сообщение «Ошибка ожидания блокировки таблицы Журналы». Вся проблема кроется в том, что записи о всех документах содержатся в одной таблице 1SJOURN, а при записи или проведении документа, 1С: Предприятие 7.7 блокирует эту таблицу, т.е. в один момент возможно проведение только одного документа любого типа. Вторая проблема — это медленное формирование отчетов, да и вообще разных запросов к остаткам или оборотам, выборки документов, особенно если вы попробуете использовать для этого встроенный язык запросов. На фоне всего этого работа с 1С:Предприятем 7.7 преврящается в сплошное мучение. Каковы пути решения этих проблем? Их несколько:

1. Если у Вас dbf база, то купить SQL версию, конвертировать в нее вашу базу, и на некоторое время вам ее хватит.
2. Купить более производительное железо, эффект будет заметен сразу но не надолго, все зависит от темпа роста базы.
3. Выделить специальную базу для формирования отчетов. Такое решение можно увидеть во многих крупных фирмах. По ночам настраивается обновление этой базы, и все пользователи, которым хватит актуальности отчетов в один день, «выгоняются» в нее, тем самым разгружается основная база.
4. Ревизия конфигурации. Вынесение отдельных операций за пределы модуля проведения документа для сокращения времени транзакции. Применение в отчетах и участках кода ответственных за сбор данных прямых SQL запросов с помощью внешней компоненты 1С++ (они дают прирост скорости на порядок, а то и больше все зависит от правильности составления SQL запроса, проверено на своей конфигурации).
5. Применение механизма гибких блокировок. Самый пожалуй шаткий путь, ибо очень опасно идти по нему. Если что не так пойдет, то приется отвечать головой за данные.

Вот короткий перечень того как можно продлить жизнь 1С: Предприятия 7.7, т.к для многих фирм переход на 8.0 или другой программный продукт может оказаться еще сложнее. Но если Ваша фирма динамично развивается от перехода вас уже скорее всего ничего не спасет, главное при переходе решить а нужна-ли вам 1С или все-таки вы уже выросли из ее архитектуры и вам стоит рассмотреть другие системы.

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

Введение

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

Основные угрозы информационной безопасности

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

1. Действия «непреодолимой» силы – к ним относятся перебои в электроснабжении, пожары, технические неисправности не связанные с эксплуатацией компьютеров, действия окружающей среды. Как правило все эти ситуации возникают по причине неправильной или недостаточной организации технической эксплуатации помещений где находятся компьютеры. Например прорыв системы отопления способен свести на нет все меры защиты информации.
2. Программно-аппаратный сбой. Неправильная настройка программного обеспечения или неправильный режим эксплуатации рабочих станций или серверов, хаотичность при проектировании и прокладке сети все это может привести к сбоям и потерям информации.
3. Недостаточная квалификация пользователей. Самая частая и банальная причина потери информации в результате действия вирусов напрямую связана с этим пунктом. Зачастую пользователи сами скачивают из интернета файлы или открывают зараженные вложения в письма не думая о последствиях своих действий.
4. Неосторожность, повлекшая за собой уничтожение информации.
5. Преднамеренное уничтожение информации.

Утечка информации как правило происходит в следующих случаях:

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

Концепция обеспечения комплексной информационной безопасности.

1. Этап.

На данном этапе исследуется:

1. возможность проникновения в корпоративную сеть через общедоступные сети или модемные пулы;
2. используемое в фирме программное обеспечение, его версии и наличие в нем критически ошибок дающих возможность провести атаки типа переполнение буфера с возможностью выполнения кода, эскалация прав, отказ в обслуживании, особое внимание уделяется антивирусным программам и актуальности антивирусных баз данных;
3. аудит рабочих мест на предмет использования приемов социальной инженерии, возможности утечки информации или ее повреждения через данное рабочее место;
4. политика безопасности в сети, стойкость паролей, частота их смены, распределение прав пользователей, существующая система ограничения доступа и централизованного хранения ключевой информации, наличие доступа в интернет вообще и к каким службам конкретно (ICQ, e-mail, HTTP, FTP, NNTP и т.п.);
5. аппаратное обеспечения информационных систем, организация рабочих мест пользователей, оборудование серверной, защищенность от аппаратных сбоев, соблюдение основных правил технической эксплуатации помещений;
6. методика и частота создания резервных копий ключевой информации.

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

2. Этап.

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

3. Этап.

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