Category: Uncategorized

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

• Первая – это физические катастрофы, т.е. природные катастрофы, такие как штормы, ураганы и т. д., которые могут разрушить ваше рабочее место; кроме того, ущерб может быть оценен в тысячи долларов. Не имея много места, малые предприятия не могут противостоять этой катастрофе, и, следовательно, они могут быть стерты с лица земли. FEMA заявляет, что более 35% малых предприятий, переживших такое бедствие, не могут возобновить свою работу. Если вы хотите убедиться в том, что ваш бизнес хорошо защищен, необходимо разработать план аварийного восстановления и адекватный страховой полис. План DR включает обязательную резервную копию данных, более того, необходимо сделать одну резервную копию и сохранить ее в любых облачных сервисах. Кроме того, с помощью защиты сайта страховка малого бизнеса может покрывать расходы на ремонт и восстановление.
• Ошибка в работе аппаратных средств – одна из четырех главных бедствий, которые влияют на малые и средние компании. В результате появляется время простоя, а иногда и прибыль и производительность снижаются. В соответствии с исследованиями Storage Craft, аппаратный сбой был связан с 99% предприятий. Кроме того, около 81% этих сбоев, по-видимому, были сбоями жесткого диска. Чтобы справиться с такой катастрофой, важно составить план B, для последующего восстановления данных.
• Вредоносные программы и кибератаки считаются еще одной опасной проблемой для бизнеса. Такие атаки приводят к краже данных, их повреждению или удалению, поэтому некоторые операции могут быть нарушены. Чтобы защитить ваш бизнес от такого рода бедствий, необходимо установить обновления безопасности. Согласно Gartner, ИТ-специалисты знают о 99% проблем компании около 1 года. И только сохранение исправленной системы и других мер безопасности может помочь защитить вашу систему от кибератак. Кроме того, вы можете восстановить свои данные до того, как они будут повреждены, если у вас есть план резервного копирования.
• Внезапная потеря ключевого персонала, по-видимому, входит в число 4 опасных рисков для небольших компаний. Хотя в крупных компаниях эту потерю можно восполнить из-за большого количества рабочих, в небольших компаниях это невозможно. Потеря рабочего может нарушить ежедневные операции. В этом случае можно принимать во внимание дублирования функций ключевых сотрудников.

У Вас еще нет плана действий при аварийных ситуациях? Обращайтесь office@itfb.com.ua

Информационная безопасность ИТ: особенности SOAR от ServiceNow

ServiceNow представляет собой гибкую платформу с широкими возможностями конфигураций, подходящими под запросы клиентов. В последнее время отделам ИБ, состоящим из пяти и более специалистов, рекомендуют использовать системы безопасности SOAR. Что же предлагает в рамках таких систем ServiceNow?

Трудности компаний с управлением информационной безопасностью

Если IT-компания не применяет в своей практике системы безопасности, то появляется риск столкнуться со следующими трудностями:

1. не определены четкие критерии полной информационной безопасности;
2. ограничена «видимость» рисков;
3. отсутствует отслеживание уязвимости системы на различных уровнях;
4. замедлено время отклика на инцидент;
5. решение возникших проблем «вручную».

Всё перечисленное неминуемо ведет к увеличению финансовых расходов на решение проблемных ситуаций отделом ИБ. Чтобы этого избежать, все же следует обратить внимание на Security Operations, Analytics and Reporting – SOAR от ServiceNow.

Функции SOAR для обеспечения ИТ безопасности компании

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

К основным функциям SOAR относятся:

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

Огромный «плюс» SOAR – полная автоматизация процессов управления ИБ: начиная от назначения приоритетности и заканчивая ответами на возникшие инциденты.

SOAR: работа модулей

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

Первый модуль – Security Incident Response, упрощает проведение идентифицирования инцидентов. Он также занимается импортированием информации из применяемых решений, а также отвечает за кастомизацию процессов.

Чтобы расставить приоритетность уязвимостей, используется модуль Vulnerability Response, который помогает определять подверженность угрозам для бизнес-критических систем. Так, благодаря этому модулю производится:

• анализ зависимостей;
• оценка влияния производимых действий на бизнес-процессы, а также простоев;
• внесение необходимых изменений;
• проверка выполненных изменений.

Еще один из важных модулей SOAR – Threat Intelligence. Он необходим для:

• обнаружения индикаторов возможной компрометации;
• отслеживания угроз на глубоких уровнях.

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

Благодаря подобной организации работы с инцидентами усиливаются позиции тех специалистов, которые работают в аналитических отделах компании, – улучшается их взаимодействие со специалистами других отделов IT-компании.

Наша компания предлагает услуги по внедрению систем информационной безопасности, office@itfb.com.ua

Большая часть организаций заполняет службу каталогов Azure AD учетными записями пользователей и групп посредством их репликации из среды Active Directory Domain Services локальной сети. Если вы таким образом создаете исходные учетные записи пользователей, существует три подхода к управлению запросами аутентификации пользователей Azure AD.

• Azure AD выполняет аутентификацию. Это возможно при условии, что хеш пароля пользователя (или скорее хеш от хеша пароля) дублируется в Azure AD. Это самый простой вариант, который не требует коммуникации с инфраструктурой AD локальной сети. Кроме того, это означает, что контроллеры домена DC локальной сети нс заботятся об аутентификации и не управляют ею.

• Используется федерация, например, службы ADFS. В этом случае Azure AD настраивается на использование федеративных отношений для аутентификации. Когда появляется запрос на аутентификацию, пользователь перенаправляется в службу федерации, которая выполняет аутентификацию, используя AD локальной сети. Это более сложное развертывание, но оно открывает перед вами всю мощь ADFS в отношении аутентификации. Данный процесс предусматривает использование аутентификации, основанной на сертификате, согласовании с другими системами многофакторной аутентификации MFA, техническом состоянии устройства и местоположении, а также других возможностей политик ADFS (или какой бы
то ни было платформы, используемой в качестве службы федерации). Обратите внимание, что, выбирая этот вариант, вы можете реплицировать хеш-пароли в Azure AD из предыдущего варианта и использовать их как альтернативный подход к аутентификации, если службы федерации недоступны.

• Используется сквозная аутентификация. Это самый новый из всех способов, который предлагается как дополнительная возможность Azure AD Connect. В этом случае в локальной сети разворачиваются агенты, которые просматривают очередь запросов на аутентификацию в Azure AD (агенты создают исходящее соединение с Azure AD. что означает отсутствие указания исключений для брандмауэра). Когда пользователь аутентифицируется на уровне Azure AD, запрос добавляется в очередь. Один из агентов сквозной аутентификации локальной сети принимает запросы, выполняет аутентификацию на контроллере домена DC локальной сети и сообщает об успешном или неудачном выполнении. Преимущество этого подхода состоит в том, что используются контроллеры домена локальной сети для выполнения реальной аутентификации. При этом организации разрешается осуществлять более жесткий контроль и возникает прозрачность аутентификации, поскольку исключаются требования к инфраструктуре, которые есть в случае с федерацией. Обратите внимание, что дополнительные копии агента сквозной аутентификации должны быть развернуты в локальной сети после развертывания одного стандартного экземпляра с Azure AD Connect для обеспечения высокой доступности службы.

Хотя я часто произношу слова «служба каталогов AD или контроллеры домена локальной сети», это не озна­чает, что они на самом деле обязательно должны быть в локальной сети. Они могут размешаться на других ресурсах, таких как виртуальные машины Azure IaaS т. д. Я просто имею в виду, что они не располагаются в Azure AD.

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

Миграция и сопровождение серверов и сервисов Azure, office@itfb.com.ua

Eсли вы хотя бы поверхност­но следите за технически­ми новинками, то, конечно, слышали о Spectre и Meltdown (http://www.datacenterknowledge.com/security/intel-microsoft-dcal- widespread-chip-security-vulnerability), двух уязвимостях, не похожих на все известные прежде, поскольку это аппаратные, а не программные изъяны в системе безопасности. Кроме того, они заслуживают внимания, поскольку присутствуют почти в каждом процессоре, изготовленном за несколько прошедших десятилетий.

Устранение уязвимости в ОС Linux, обращайтесь office@itfb.com.ua

У многих пользователей, возможно, создалось впечатление, что Spectre относится к процессорам Intel, AMD и ARM, a Meltdown затрагивает только продукцию Intel или все процессоры Intel и некоторые микросхемы ARM. Это не так, как разъяснил нам Джон Мастерс из компании Red Hat. Обе уязвимости свойственны всем архитектура без исключения. «Полагаю, на долю Intel пришлось нео­правданно много внимания,— поясняет Мастерс на сайте Data Center Knowledge.— Проблема затрагивает не только Intel, AMD и ARM, но и любую современную архитектуру».

Мастерсу это должно быть известно не понаслышке. Хотя его основная должность— главный архитектор ARM в компании Red Hat, он стал одним из тех специалистов, которые возглавили усилия по борьбе с Meltdown и Spectre.

Вопрос об Intel возник, когда Мастерс рассказывал о влиянии мер для противодействия Meltdown на производительность в компани­ях, имеющих большое число серве­ров. В некоторых статьях в прессе указывалось, что после применения исправлений производительность серверов может снизиться до 30%. Специалисты Red Hat считают, что потери составят до 20%.

«Наши обновления изначально следуют в русле политики без­опасности Red Hat,— подчеркнул Мастерс.— Мы всегда будем делать их максимально надежными, поэ­тому, устанавливая обновления, клиенты наверняка столкнуться со снижением производительности. Однако они могут провести анализ рисков и решить, до какой степени нуждаются в полной безопас­ности. Например, в закрытой лабо­раторной среде, для высокопроизво­дительных вычислений и т. д., когда существует очень высокая степень контроля, можно будет обойтись без защитных мер. В таких условиях можно отключить их и вернуть 99% производительности».

Потери производительности при полной защите зависят в первую очередь от рабочей нагрузки ком­пьютера.

«На наших тестах было очень мало нагрузок порядка 18-20%,— пояс­няет Мастерс.— Большинство рабочих нагрузок находятся в диа­пазоне от 5 до 10%, в зависимости от поставщика и поколения про­цессора».

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

«Я действительно полагаю, что в долгосрочной перспективе уязвимость не так важна, как сейчас о ней говорят,— заявил Мастерс.— Да, это опасная угроза. Нет сомнений, что ее нужно устранить как можно скорее. При этом атака чрезвычайно сложная. Уязвимость потенци­ально существует уже несколько десятилетий в различных семействах процессоров. Атака такого класса теоретически возможна, но, чтобы отыскать слабое место, потребовалось много усилий. Воспроизвести атаку очень трудно. Вряд ли многим удалось найти способ сделать это самостоятель­но, прежде чем способ стал обще­известен, а устранить угрозу срав­нительно нетрудно».

Ошибка Spectre на самом деле пред­ставляет собой две связанные уяз­вимости и также стала причиной опасений, когда на нескольких новостных сайтах появились сообщения о том, что устранить изъян безопасности невозможно. Однако это не совсем верно, как утверждает Мастерс, хотя устранить угрозу нс так просто, как в случае с Meltdown.

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

Однако это не особенно беспокоит Мастерса, поскольку атака через Spectre практически невозможна.

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

«Для смягчения проблемы Meltdown не потребуется очень сложных изме­нений логики, — отметил Мастерс, предупредив, что он не констру­ирует процессоры.— Изменение довольно простое и внедряет­ся очень быстро. Конечно, время изменений в аппаратной конструк­ции измеряется величинами друго­го порядка, нежели программные изменения. Для атаки Spectre изме­нение очень простое, и его неслож­но будет реализовать в устройствах следующих поколений».

Для Spectre потребуются некоторые изменения в программном обеспечении, и, возможно, поэтому в некоторых сообщениях уязвимость называют неустранимой. «Первый компонент Spectre легко устранить программным способом, который, в сущности, не приводит к снижению производительности,— объясняет Мастерс.— Но его очень трудно устранить аппаратно. Скорее, всего, нам придется жить с первым компонентом Spectre долгие годы. Чтобы автоматически устранять уязвимость, потребуется изменить пакеты инструментальных средств, компиляторы и т.д. Пока же мы используем средства сканирования, которые проектировались для поиска уязвимость, и вставляем небольшие фрагменты кода в ядро, чтобы предотвратить проблему»

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

Почему аудит не может стоить дешево? Если мы сейчас забьем аудита ит-инфраструктуры в поисковой строке, в поисковой системе то увидим массу предложение аудита ИТ от 20$. Это нереально сделать за такие деньги аудит. Я сейчас поясню почему. Средний специалист высокого класса, который занимается аудитом, имеет определенную зарплату мы с вами говорили в предыдущих статьях о том что зачастую на аудит привлекаются сотрудника 3-4 разных специализаций. Это уже 3-4 человека. Продолжительность аудита как правило от 2 недель до 2 месяцев, банально перемножив зарплату этих людей мы не можем получить цифру в 20-30$. Возможно если проводится аудит, не всей ИТ инфраструктуры, а например только сайта или одного сервера, и время затраченное на аудит измеряется часами, то стоимость может быть до 100$, но никак не комплексный аудит. Поэтому если вам предлагают аудит за какие-то смешные деньги, Вы должны задать себе вопрос, кто будет делать этот ИТ аудит? Как он будет выглядеть? Что будет на выходе? Как будет выглядеть отчет,  какой он будет по объему? И вообще есть ли опыт у людей проведения аудитов.

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

В предыдущей статье мы говорили о том когда нужно проводить аудит ИТ.

Как выглядит типичная процедура аудита.

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

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

Этап достаточно длинный, поскольку отчёты по аудиту могут быть в несколько десятков, а иногда и сотен страниц. Поскольку читать 200 страниц отчета по аудиту достаточно сложно, особенно для представителей бизнеса, у ИТ аудита всегда есть резюмирующая часть, где подводятся итоги аудита, описываются проблемы и пути их решения. То есть для людей принимающих решения в принципе достаточно читать последние 10-20 страниц. Хотя весь отчет конечно будет полезен для тех специалистов, в том числе технических специалистов, которые работают в компании, чтобы впоследствии следовать рекомендациям аудита и минимизировать риски, убрать все недостатки.

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

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

1 сценарий

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

 2 сценарии

Когда обращаются за IT аудитом в случае если, есть сомнения в безопасности системы или сервиса компании. Cамый распространенный сценарии – это ситуация когда у людей есть ресурсы доступны из интернета. Это может быть интернет магазин или какие-то другие решения в таком случае проблема с безопасностью в IT может привести не только к потере или компрометации данных но и к серьезным репутационным потерям. Естественно компании обращаются с одним вопросом оцените нашу систему и расскажите, как её защитить.

3 сценарии

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

4 сценарий

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

Сразу хотелось бы ответить на вопрос почему аудит не проводится силами внутренних сотрудников? Почему для проведения аудита приглашают людей со стороны? Что такое вообще и ИТ аудит и аудит в частности?

Аудит- это экспертная оценка какой-то системы или продукта. Если мы говорим об ИТ аудите – то это экспертная оценка, независимыми специалистами, какого-то сервиса или ИТ продуктов компании. Так вот почему приглашают людей со стороны.  Специфика аудита подразумевает, что нужны специалисты экстра-класса и в ряде случаев компания просто не имеет специалистов такого уровня у себя в штате. Они просто были не нужны. Плюс нужно понимать, что для проведения аудита специалисты должны обладать весьма широким кругозором, опытом. Они должны иметь опыт работы в разных компаниях, работать с маленькими, средними и крупными компаниями. Работать в самых различных сценариях. Только такой специалист сможет комплексно оценить ту или иную систему. Опять же когда человек работает в компании, то как правило он заточен на выполнение только задач с специфики той компании, где он трудится и смотреть комплексно ему гораздо сложнее. Плюс нужно понимать, что для проведения аудита необходимо как правило 3-4 специалиста абсолютно разной направленности. Это специалисты по безопасности, специалисты по сетевой инфраструктуре, специалисты по объединенным коммуникациям. В компании просто может не быть такого набора специалистов. Аудит всегда достаточно долгая процедура по времени и он занимает от 2 недель до нескольких месяцев. Достаточно сложно взять собственных сотрудников и выключить их их из работы, например, на 2 месяца. Надо понимать, что у них должен быть независимым взгляд. Когда аудит проводят собственные сотрудники, добиться беспристрастности достаточно сложно.

Наша, компания, обладая большим опытов работы в ИТ и разнонаправленных специалистов, проводит IT аудит, обращайтесь office@itfb.com.ua

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

Конкретного ответа на вопрос, что должен знать и уметь системный администратор – нет, так как требования к специалистам в каждой организации разные, их могут описать в объявлении при поиске кандидата на вакантную должность и/или огласить на собеседовании. Зачастую указываются знания продуктов известных фирм, исполь­зование программно-аппаратных комплексов, платформ, различных технологий, конкретных программ с точностью до определенной версии и тому подобное.

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

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

Достоинства: использование новых технологий, сокра­щение времени на ручной труд.

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

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

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

А так же можно нанять удаленного системного администратора, для решения любых ИТ задач, office@itfb.com.ua