طراحی و معماری زیرساخت کلید عمومی یا PKI قسمت اول – شناسایی نیازمندیهای PKI

یکی از مهمترین مباحثی که در خصوص رمزنگاری داده ها وجود دارد زیرساختار کلیک عمومی یا PKI است ، این نوع رمزنگاری از نوع نامتقارن است که دارای دو کلید است که یکی برای رمزنگاری و دیگری برای رمزگشایی استفاده می شود ، معمولا تا نامی از ساختار PKI در سیستم عامل های مایکروسافت می آید به فکر سختی ها و ابهاماتی می افتیم که همیشه در این مسئله جزئی از کار هستند ، اکثر ایرانی هایی که در راه اندازی PKI دستی دارند و در سازمان خود از PKI های مایکروسافتی استفاده می کنند ، از مفاهیم موجود در آن اطلاعاتی ندارند و صرفا آن را نصب می کنند ، در این سری مقالات ضمن بررسی چیستی PKI به بررسی و طراحی این ساختار بصورت اصولی در سیستم عامل های مایکروسافت خواهیم پرداخت . در شبکه های تحت سیستم عامل ویندوز سرور 2008 زیرساخت کلید عمومی یا PKI به یک یا چندین Certificate Authority یا CA گفته می شود که از طریق سرویس Active Directory Certificate Services پیاده سازی شده باشند. تعجب نکنید در خصوص تمامی این واژه ها در ادامه توضیحات کاملی را ارائه خواهیم داد اما توجه کنید که پیاده سازی PKI به همین سادگی ها نیست که صرفا در Server Manager یک Role نصب کنید و کار تمام شود. برای بیشتر سازمان های متوسط و رو به بزرگ پیاده سازی PKI نیازمند طراحی اولیه و تهیه مستندات است.

مدت ها بود که استفاده از زیر ساختار PKI در سازمان ها چندان معمول نبود تا اینکه اکثر نرم افزارهای کاربردی و سرویس های شبکه برای بالا بردن سطح امنیتی خود استفاده از PKI را در زیرساخت نرم افزاری خود به عنوان یک الزام قرار دادند و این خود دلیلی بود که سازمان ها نیز به سمت استفاده از PKI بروند . قطعا اگر سازمان شما از استانداردهای بین المللی امنیت اطلاعات مانند ایزو 27001 استفاده می کند و یا حداقل چیزی به عنوان خط مشی امنیت سازمان وجود دارد استفاده از PKI معمولا در این سیاست های کلان دیده می شود. اگر در خط مشی امنیتی سازمانی شما PKI دیده شده است که به ندرت چنین چیزی در ساختارهای سازمانی ایران دیده می شود به سراغ بررسی نیازمندیهای اولیه PKI از قبیل نیازمندیهای تجاری ، نیازمندیهای خارجی و نیازمندیهای اکتیودایرکتوری می رویم . بعد از اینکه تمامی این موارد را بررسی کردید که با توجه به تجارب بنده بررسی نخواهید کرد به سراغ طراحی PKI برای سازمان می رویم و آن را در بر اساس خط مشی امنیتی سازمان و نیازمندیهای سازمان جلو می بریم.


 

مروری بر مفاهیم PKI


PKI مخفف کلمه Public Key Infrastructure یا زیرساخت کلید عمومی می باشد که در واقع یک سری از تکنولوژی ها هستند که به شما امکان استفاده از رمزنگاری نامتقارن یا در لفظی دیگر رمزنگاری کلید عمومی را می دهند. در رمزنگاری کلید عمومی یک جفت کلید با استفاده از الگوریتم های رمزنگاری ریاضی تولید می شوند که به نام های کلید عمومی یا Public Key و کلید خصوصی یا Private Key معرفی می شوند ، با استفاده از مجموع این دو کلید شما می توانید عملیات رمزنگاری و رمزگشایی اطلاعات را انجام دهید. اگر کلید خصوصی برای رمزنگاری استفاده می شود ، صرفا کلید عمومی مرتبط با آن می تواند اطلاعات مربوطه را رمزگشایی کند. عکس همین عمل هم ممکن است و اگر شما با کلید عمومی چیزی را رمزنگاری کنید ، صرفا با کلید خصوصی مرتبط با آن عملیات رمزگشایی انجام خواهد شد. اگر بخواهیم تخصصی تر در این مورد توضیح بدهیم می توانیم بگوییم که PKI یک سیستم است که از ترکیبی از گواهینامه های دیجیتال ( Digital Certificates ) ، مراکز صدور گواهینامه ( Certificate Authorities ) و مراکز ثبت گواهینامه ( Registration Authorities ) تشکیل شده است که در مجموع می توانند سرویسی برای رمزنگاری اطلاعات ایجاد کنند که بتواند تبادلات الکترونیک را رمزنگاری و یا اشخاص را احراز هویت کنند. ساختار PKI در ساده ترین حالت شامل اجزای زیر می باشد:

  • گواهینامه های دیجیتال یا Digital Certificates : در ترجمه به معنی اعتبار است اما بهتر است بگوییم که Credential های الکترونیکی می باشند که شامل کلید عمومی هستند که برای رمزنگاری داده ها و استفاده به عنوان امضاء الکترونیکی استفاده می شوند. در واقع Digital Certificate ها پایه و اساس کار PKI هستند و بدون آنها PKI بی معنی است.

 

  • یک یا بیش از یک مرکز صدور گواهینامه دیجیتال یا Certificate Authority : مراجع یا موجودیت های مورد اعتمادی هستند که برای صدور Digital Certificate ها مورد استفاده قرار می گیرند. زمانیکه از بیش از یک عدد CA در یک مجموعه استفاده می شود ، همیشه برای آنها یک نظم در طراحی وجود دارد که وظایف هر یک از آنها را به تفکیک روشن کرده است ، برای مثال CA ریشه یا Root در هسته اصلی مرکز قرار دارد ، در زیر مجموعه Root CA مرکزی به نام Subordinate CA وجود دارد و در نهایت مرکزی برای صدور گواهینامه برای کاربران به نام Issuing CA وجود دارد.

 

  • Certificate Policy و Certificate Practice Statement : اینها دو عدد مستند مکتوب هستند که در آنها شیوه استفاده از CA و همچنین Certificate هایی که در آن وجود دارند تشریح شده است و همچنین درجه اعتمادی که می توان به Certificate های این مجموعه داد را تعیین می کند ، تمامی موارد و مسائلی که در خصوص از بین رفتن اعتماد به CA و از این قبلی مشکلاتی که در ساختار PKI به وجود می پیوندند در این مستندات دیده شده است.

 

  • Certificate Repository: محلی است که مانند یک ساختار directory Service که از اکانت های کاربری محافظت می کند ، از Certificate های تولید شده توسط ساختار PKI موجود محافظت و آنها را ذخیره می کند ، Certificate ها از این محل منتشر می شوند . در یک محیط دامین معمولا پایگاه داده اکتیودایرکتوری معمولترین Repository است که برای انتشار و نگهداری Certificate ها مورد استفاده قرار می گیرد.

 

  • Certificate Revocation List یا CRL : لیستی از Certificate هایی است که قبل از اینکه تاریخ انقضای آنها برسد بر اساس شرایط بوجود آمده باطل یا Revoke شده اند.

 


 

شناسایی ابزارها و سرویس های کاربردی PKI یا PKI-Enabled Applications


همیشه زمانی استفاده از یک تکنولوژی باب می شود که نیازی به استفاده از آن ایجاد شود و PKI هم از این قضیه استثناء نیست . سازمان هایی که امروزه از PKI استفاده می کنند نیاز به استفاده از آن را بیشتر در نرم افزاهای کاربردی و سرویس هایی می بینند که برای بالا بردن سطح امنیت خود از PKI استفاده می کنند. بعد از اینکه نیاز به PKI ملموس شد سازمان مجبور می شود که بر اساس نیاز پشتیبانی های لازم برای برآورده سازی نیازهای راه اندازی PKI را برطرف کند. در ادامه لیستی از تکنولوژی های و نرم افزارهای کاربردی که سازمان را مجبور به استفاد از PKI می کند را به شما معرفی خواهیم کرد :

  • 802.1x Port Based Authentication : این قابلیت به شما اجازه می دهد که بتوانید دسترسی به شبکه وایرلس و یا شبکه اترنت خود را برای کاربران غیرمجاز مسدود کرده و صرفا به کسانی اجازه متصل شدن به سیستم را بدهند که از طریق 802.1x احراز هویت شده اند. زمانی که شما در این سرویس از پروتکل های Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS یا (Protected Extensible Authentication Protocol (PEAP استفاده می کنید بایستی از ساختار PKI استفاده کنید.

 

  • امضای دیجیتال یا Digital Signatures : مهمترین رکن در امضاهای دیجیتال ساختار PKI است . Digital Signatures تبادلاتی که در اینترنت انجام می شوند را امن می کنند و روشی را برای شما فراهم می کنند که متوجه بشوید چه کسی ، چه اطلاعاتی و چه محتوایی را منتقل کرده است و از طرفی از دستکاری نشدن اطلاعات نیز اطمینان حاصل می کند. بسته به روشی که Certificate صادر شده است شما می توانید از امضاهای دیجیتال برای انکارناپذیری یا non-repudiation نیز استفاده کنید ، بدین معنی که اگر کسی کاری را انجام داده است نتواند انجامش را انکار کند. در این حالت اگر شخصی اطلاعاتی را منتقل کند ، نمی تواند منکر این قضیه شود به دلیل اینکه صرفا کسی که دارای Private Key مربوطه می باشد توانایی انتقال چنین داده ای را دارد.

 

  • Encryption File System یا EFS : این قابلیت ، سرویس محرمانگی یا Confidentiality را به NTFS می دهد. در این قابلیت از دو کلید عمومی و خصوصی برای رمزنگاری و رمزگشایی فایل ها و همچنین برای بازیابی اطلاعات در مواقع ضروری یا Recovery Agent استفاده می شود. Certificate هایی که برای EFS ایجاد می شوند صرفا از طریق Enterprise CA ها امکان صدور دارند ، در جایی که شما Enterprise CA در اختیار ندارید هرگاه از EFS استفاده کنید ، Certificate ها بصورت Self-Signed صادر و استفاده می شوند.

 

  • IPSec : اگر با پروتکل امنیتی IPSecurity یا IPSec آشنایی داشته باشید حتما می دانید که این پروتکل برای رمزنگاری و همچنین Tunneling بین دو سیستم برای برقراری ارتباط امن مورد استفاده قرار می گیرد ، اما برای اینکه بتوانید ساختار احراز هویت را نیز به IPSec اضافه کنید می توانید از Certificate ای که در PKI تولید می شود استفاده کنید. IPSec می توانید ارتباطات بین دو Endpoint را به خوبی Digitally Sign کند. توجه کنید که Certificate های بصورت مستقیم برای رمزنگاری داده هایی که توسط IPSec منتقل می شوند استفاده نمی شوند بلکه برای Authentication یا احراز هویت دو Endpoint استفاده می شوند.

 

  • Secure E-Mail یا S/MIME : پروتکل Secure Multipurpose Internet Mail Extensions یا همان SMIME برای برقراری ارتباطات ایمیل محرمانه ، دارای تمامیت و صحت اطلاعات و انکارناپذیری استفاده می شود. SMIME از Certificate برای شناسایی هویت فرستنده ، اصل و ماهیت پیام ارسالی و صحت و تمامیت پیام ایمیل استفاده می کند. همچنین SMIME محرمانگی پیام ایمیل را با استفاده از رمزنگاری اطلاعات درون آن انجام می دهد.

 

  • کارت های هوشمند یا Smart Card : کارت های هوشمند شبیه کارت های اعتباری هستن که در آنها Certificate کاربر ذخیره می شود. شما می توانید با استفاده از کارت های هوشمند فرآیند احراز هویت Two Factor با درجه امنیتی بالاتری نسبت به رمزعبور خالی برای ورود به سیستم ها ایجاد کنید.

 

  • Code Signing : با استفاده از قابلیت Code Signing شما می توانید از نصب درایورها یا نرم افزارهای غیر مجاز بر روی سیستم جلوگیری و محافظت کنید ، نرم افزارهایی که از قابلیت Code Signing پشتیبانی می کنند مانند Microsoft Internet Explorer می توانند به گونه ای تنظیم شوند که از اجرا کنترل ها و کدهای Unsigned جلوگیری کنند.

 

  • Virtual Private Network یا VPN: سرویس VPN به شما اجازه برقراری ارتباط از راه دور با شبکه های خصوصی از طریق پروتکل های Tunneling از قبیل PPTP و L2TP و SSTP را می دهد. البته تمامی پروتکل های VPN از Certificate برای برقراری ارتباط استفاده نمی کنند بلکه پروتکل L2TP زمانیکه از IPSec استفاده می کند از Certificate برای فرآیند احراز هویت استفاده می کند و از طرفی کلیه فعالیت های SSTP که با SSL رمزنگاری می شود از Certificate برای اینکار استفاده می کند.

 

  • Web Authentication و SSL: این دو سرویس با استفاده از این دو سرویس با استفاده از Certificate ها می توانند برای وب سرور قابلیت رمزنگاری اطلاعات مربوط به احراز هویت در شبکه داخلی و یا اینترنت را فراهم کند ، با استفاده از SSL کاربران وب می توانند از هویت اصلی و واقعی بودن سرور وب اطمینان حاصل کنند و تمامی ارتباطات بین کلاینت و سرور رمزنگاری خواهد شد. تمامی وب سرورهایی که دارای سرویس SSL هستند دارای Certificate هستند که توسط یک Third Party CA معتبر صادر می شود اما در برخی از مواقع پیش می آید که شما می توانید از Certificate ای که Client ها دارند برای سرور هم استفاده کنید که این مورد معمولا به ندرت پیاده سازی می شود.

 


 

شناسایی نیازمندیهای Certificate


بعد از اینکه تعیین کردید که از کدامیک از سرویس ها یا نرم افزارهای مرتبط یا PKI می خواهید در سازمان خود استفاده کنید ، بایستی تعیین کنید که چه کسی مسئول صدور Certificate ها و نوع Certificate ای خواهد بود که قرار است صادر شود. معمولا Certificate ها به شکل زیر صادر می شوند :

  • User Certificate: این نوع Certificate برای یک کاربر خاص صادر می شود که قرار است از سرویس ها یا نرم افزارهای PKI استفاده کند. کاربر مورد نظر در این حالت یک Certificate مخصوص به خود دریافت می کند که با استفاده از آن می تواند از سرویس ها و قابلیت های PKI مختص یک کاربر مانند سرویس EFS که برای رمزنگاری اطلاعات یک کاربر خاص مورد استفاده قرار می گیرد استفاده کند ، این Certificate در این حالت صرفا برای مصرف EFS مورد استفاده قرار می گیرد . Certificate هایی که برای کاربران صادر می شود در Current User Certificate Store ذخیره می شوند.

 

  • Computer Certificate: این نوع Certificate همانطور که از نامش پیداست صرفا برای یک کامپیتور صادر می شود و زمانی که یک کامپیوتر یا یک User به این کامپیوتر متصل می شود این Certificate هویت واقعی این کامپیوتر را مشخص می کند. این Certificate هویت کامپیوتر را مشخص می کند و در قسمت Local Machine Certificate Store ذخیره می شود.

 

  • Network Device Certificate : برخی از سخت افزارهایی که در شبکه فعالیت می کنند می توانند از امکانات و سرویس هایی که PKI در اختیار آنها قرار می دهد استفاده کنند و احراز هویت کلاینت ها و سرورها را با استفاده از PKI انجام دهند. این دستگاه ها شامل تجهیزات سخت افزاری VPN و Firewall و Router ها هستند اما فقط به اینها محدود نمی شوند. فرآیند نصب یک Certificate بر روی یک دستگاه بستگی به نوع سیستم عامل بکار رفته بر روی دستگاه مورد نظر و از طرفی Interface های شبکه ای دارد که بر روی دستگاه مورد نظر وجود دارد. Network Device Enrollment یک امکان جدید است که در CA های مایکروسافت بر روی ویندوز سرور 2008 معرفی شده است ، این قابلیت وابستگی مستقیمی به سرویس Network Device Enrollment Service یا NDES دارد. این سرویس در واقع معادل مایکروسافتی سرویسی به نام Simple Certificate Enrollment Protocol یا SCEP است ، این سرویس در واقع یک پروتکل است که به شما امکان پیاده سازی استاندارد X.509 را بر روی سخت افزارها و دستگاه هایی که قابلیت احراز هویت در شبکه را دارند فراهم می کند و این بدین معناست که این دستگاه ها می توانند از CA برای خود Certificate دریافت کنند.

 

  • Service Certificate : سرویس ها نیز برای احراز هویت و رمزنگاری از Certificate هایی که برای کامپیوترها صادر می شود استفاده می کنند. Certificate ها در واقع برای سرویس ها صادر نمی شوند بلکه در عوض Certificate ای که برای کامپیوتر صادر می شود و توسط سرویس مورد استفاده قرار می گیرد در Local Machine Store یا در پروفایل اکانت سرویس مورد نظر ذخیره می شود. برای مثال اگر یک Certificate برای سرویس World Wide Web یا WWW یک سرویس وب نصب شود ، Certificate مورد نظر در قسمت Local Machine Store ذخیره خواهد شد. از طرفی دیگر Certificate ای که برای Recovery Agent مربوط به EFS مورد استفاده قرار می گیرد در User Profile کاربر سرویس مورد نظر ذخیره می شود.


نکته : کجا باید برای یک سرویس Certificate مورد نیازش را نصب کنید ؟
ساده ترین روشی که شما می توانید تعیین کنید که آیا یک سرویس نیاز به Certificate دارد یا خیر این است که تشخیص دهید که سرویس مورد نظر به وسیله چه چیزی احراز هویت را انجام می دهند ، اگر سرویس از Local System استفاده می کند ، Certificate مورد نظر بایستی در Local Machine Store ذخیره شود و اگر سرویس مورد نظر از یک نام کاربری و رمز عبور مشخص شده استفاده می کند ، بنابراین Certificate مورد نظر در پروفایل کاربر مورد نظر ذخیره می شود.


 

شناسایی نیازمندی های امنیتی Certificate ها


نیازمندی های امنیتی Certificate ها بر اساس نوع سرویس PKI ای که قصد استفاده از آن در سازمان خود دارید ، متفاوت است . شناسایی این نیازمندی ها به شما اجازه می دهد که تنظیمات Certificate های مورد نیاز را به خوبی برآورد کنید ، برای هر مجموعه ای از Certificate ها شما بایستی نیازمندی های امنیتی زیر را به خوبی شناسایی و درک کنید:

  • طول کلید خصوصی یا Private Key Length : در یک پیاده سازی تعریف شده ، طول کلید خصوصی هایی که در یک سطح از hierarchy یا سلسله مراتب ساختار PKI قرار میگیرند نصب طول کلید خصوصی است که در سطح بالایی خود استفاده می شود. برای مثال در ساختار PKI طول کلید خصوصی که برای یک کاربر صادر می شود ممکن است 1024 بیتی باشد و در همین حال طول کلید خصوصی CA صادر کننده 2048 بیتی باشد و طول کلید خصوصی Root CA یا ریشه 4096 بیتی باشد. توجه کنید که با اگر طول کلید خصوصی شما طولانی تر باشد طبیعی است که برای شکستن این کلید زمان بیشتری از لحاظ دانش ریاضی مورد نیاز می باشد بنابراین به تناسب طول کلید بیشتر ، عمر Certificate ای که صادر می شود نیز بیشتر خواهد بود. برای انتخاب طول کلید خصوصی در هر لایه از CA ها بزرگترین مسئله قابلیت استفاده نرم افزارها و سرویس ها از کلید هایی با طول زیاد است ، برخی از سرویس ها و نرم افزارها نمی توانند از کلید هایی با طول زیاد پشتیبانی کنند.

 

  • الگوریتم رمزنگاری یا Cryptographic Algorithm : الگوریتم های رمزنگاری جزء جدا ناشدنی Certificate ها هستند. تنظیمات استاندارد Certificate هایی که از طریق CA های ویندوز سرور 2008 صادر می شوند بایستی دارای یک سری پارامترهای امنیتی پیشفرض باشند. اما گاهی برای شما پیش می آید که می خواهید برای گروه خاصی که در شبکه فعالیت می کنند تنظیماتی انجام دهید که طول کلید خصوصی آنها و عمر گواهینامه یا Lifetime آن طولانی تر یا کمتر از موراد مشابهی باشد که برای سایر کاربران وجود دارد. شما با استفاده از الگوریتم های رمزنگاری خاص می توانید روش ذخیره سازی کلید خصوصی در کارت های هوشمند را به گونه ای تعیین کنید که از درجه امنیتی بالاتری برخوردار باشند.

 

  • عمر گواهینامه یا Lifetime و کلید خصوصی و چرخه تجدید Certificate : یک Certificate در زمان صدور دارای یک تاریخ و زمان اعتبار و یک تاریخ و زمان انقضاء می باشد. شما نمی توانید اعتبار یک Certificate صادر شده را بعد از صدور تغییر دهید. عمر گواهینامه دیحیتال یا Certificate Lifetime بسته به نوع Certificate ، نیازهای امنیتی ، استانداردهای بکار گرفته شده در سازمان شما و همچنین مقررات دولتی می تواند متغیر باشد

نکته : عمر گواهینامه ها یا Certificate Lifetime : زمانی که شما می خواهید Certificate Lifetime را برای ساختار PKI خود تعیین کنید ، گزینه درست این است که Certificate Lifetime مربوط به CA های Parent یا والد را دو برابر CA های Subordinate یا میانی در نظر بگیرید. علاوه بر این زمان اعتبار یا Validity Period مربوط به CA ای که به عنوان صادر کننده یا Issuing CA مشغول به کار است را بایستی حداقل دو برابر زمان اعتبار Certificate هایی باشد که توسط همان CA صادر می شود. برای مثال شما برای یک Certificate که برای کاربر صادر می شود تاریخ اعتبار یک ساله در نظر می گیرد و این در حالی است که CA صادر کننده دارای تاریخ اعتبار 5 ساله می باشد و CA ریشه یا Root CA دارای تاریخ اعتبار 10 ساله می باشد.

  • نگهداری و ذخیره سازی کلید های خصوصی خاص یا Special Private Keys : هر سازمانی برای خود بایست دارای یک خط مشی امنیتی یا Security Policy باشد که در آن به نیازمندی های امنیتی که برای نگهداری کلید خصوصی CA وجود دارد اشاره شده باشد. برای مثال یک سازمان ممکن است برای نگهداری کلید خصوصی خود از استاندارد محافظتی Federal Information Processing Standards یا FIPS شماره 140-2 استفاده کند. در خصوص این استاندارد به امید خدا در مقاله ای جداگانه بصورت مفصل توضیحاتی ارائه خواهیم کرد.


معیارهایی که شما می توانید برای محافظت از کلید خصوصی CA خود استفاده کنید شامل استفاده از یک Cryptographic Service Provider یا CSP است که به شما این قابلیت را می دهد که بتوانید کلید خصوصی CA خود را در درون هارد دیسک کامپیوتر خود ، در داخل یک کارت هوشمند CSP که اطلاعات مربوط به کلید خصوصی را در خود ذخیره می کند و با استفاده از یک PIN Code از آن نگهداری می کند ، در داخل یک Hardware Security Module یا HSM که بالاترین سطح امنیتی را برای کلید خصوصی شما فراهم می کند ، می باشد. HSM ها سخت افزارهای ویژه ای هستند که برای نگهداری کلید های خصوصی مورد استفاده قرار می گیرند.


 

Cryptographic Service Provider یا CSP چیست ؟


یک CSP در واقع چگونگی و روش دسترسی و محافظت از کلید خصوصی یا Private Key را تعیین می کند . این CSP است که تعیین می کند در کجا زوج کلید های Certificate ایجاد شود و چه زمانی Certificate در خواست شود و همچنین مکانیزم های امنیتی برای محافظت از کلید خصوصی را نیز تعیین می کند. برای مثال در یک CSP ممکن است برای دسترسی به کلید خصوصی موجود در یک کارت هوشمند حتما یک PIN Code نیاز باشد. CSP پیشفرضی که در ساختار AD CS در ویندوز سرور 2008 وجود دارد به نام RSA#Microsoft Software Key Storage Provider است . این CSP ضمن اینکه از الگوریتم های رمزنگاری قدیمی پشتیبانی می کند ، از الگوریتم های جدید نیز پشتیبانی می کند.

بازنگری و تازه سازی خط مشی امنیتی سازمان


بعد از اینکه ساختار و نیازمندیهای PKI و Certificate ها در سازمان دیده شد ، شما بایستی خط مشی امنیتی سازمان را مجددا بازنگری کنید. خط مشی امنیت اطلاعات یا Security Policy در واقع یک مستند تدوین شده توسط اعضای قانونی یا مدیران سازمان ، منابع انسانی و دپارتمان فناوری اطلاعات یک سازمان است که در آن استانداردهای امنیتی سازمان مشخص و مستند شده است. این مستند معمولا حاوی دارایی هایی است که برای سازمان دارای ازرش هستند و تهدیداتی که در مقابل این دارایی ها وجود دارد ، در نهایت کنترل هایی که برای محافظت از این دارایی ها در مقابل تهدیدات وجود دارد در این مستند آورده شده است. خط مشی امنیت اطلاعات یک سازمان برای اینکه بتواند به سئوالاتی که در سطوح بالا از پیاده سازی های PKI به وجود می آیند پاسخگو باشند بایستی به روز رسانی شوند که نمونه ای از این سئوالات به شرح زیر می باشد:

  • چه نرم افزارهایی بایستی به وسیله Certificate ها امن شوند ؟
  • چه سرویس های امنیتی بایستی به وسیله Certificate ها ارائه شوند ؟


معمولا در زمان طراحی و معماری ساختار PKI بایستی به خاطر داشته باشیم که PKI بایستی بتواند خط مشی امنیتی سازمان را مجبور به تغییر کند . یک ساختار PKI تنها زمانی به درستی می تواند در حیطه امنیتی خود عمل کند که خط مشی امنیتی سازمان و دستورالعمل های این خط مشی بتوانند از آن پشتیبانی کنند و PKI را قابل پیاده سازی کنند.


 

ارزیابی نیازمندی های تجاری


نیازمندی های تجاری مشخص کننده اهداف یک سازمان هستند. نیازمندی های تجاری تاثیر مستقیمی بر طراحی ساختار PKI در یک سازمان دارند و در واقع PKI بایستی به نحوی طراحی شود که در راستای برآورده سازی نیازهای سازمانی و فرآیندهای کاری باشد. برای مثال نیازمندی های تجاری که در ادامه مشاهده می کنید تاثیر مستقیمی بر روی طراحی ساختار سلسله مراتبی CA ها دارند:

  • کاهش هزینه های مرتبط با PKI : در طراحی ساختار سلسله مراتبی PKI بایستی به این مورد توجه کنید که از حداقل تعداد ممکن از CA ها استفاده کنید برای مثال برخی از سازمان ها به جای استفاده از دو عدد CA به عنوان Policy CA و Issuing CA ، هر دوی آنها را بر روی یک سرور قرار می دهند تا هزینه های خود را پایین بیاورند ، در این حالت ضمن صرفه جویی در هزینه ها کارایی نیز تا حدودی در سطوح پایین ، بالا خواهد رفت.

 

  • دسترسی پذیری بالا در صدور Certificate ها : یک سازمان همیشه به یک CA نیاز دارد که در صورت بروز مشکل برای CA های صادر کننده Certificate بتواند به روند کاری خود ادامه دهد و به هر دلیلی روند صدور Certificate ها دچار اخلال نشود. برای اطمینان از دسترسی همیشگی به یک CA شما بایستی از ساختار های Clustering برای Issuing CA های خود بر اساس Certificate Template تعریف شده استفاده کنید. اگر نیاز به uptime شما زیاد هم ضروری نیست شما می توانید Certificate Template تعریف شده در Issuing CA را در CA ها مختلفی که در ساختار سلسله مراتبی وجود دارند منتشر کنید تا در صورت بروز مشکل برای یکی از CA ها فرآیند کاری در جریان باشد.

 

  • مسئولیت شرکای PKI : در یک ساختار سلسله مراتبی CA یکی از CA ها در نقش Policy CA فعالیت می کند ، این CA تعیین کننده مسئولیت های CA می باشد. این مسئولیت ها بایستی بتوانند تمامی مراوداتی که از طریق Certificate هایی که از طریق CA ها صادر شده اند را پوشش دهند. معمولا در این چنین شرایطی محلی از سازمان که مسئول قانون گذاری در سازمان شما می باشد مسئولیت ها را در این خصوص تعیین کرده و به ساختار PKI و شرکایی که از آن استفاده می کنند ابلاغ می کند.

 


 

ارزیابی نیازمندی های خارجی


در برخی اوقات پیش می آید که سازمان بایستی نیازمندی های خارجی را نیز در ساختار PKI خود در نظر بگیرد ، مثلا نیازمندی هایی که توسط سایز سازمان های طرف قرارداد یا مرتبط هستند و یا نیازمندی های کشورهایی که سازمان شما با آنها مراوده دارد ، برای مثال برخی از این نیازمندی های خارجی را می توان به شرح زیر معرفی کرد:

  • ارائه امکاناتی برای سازمان های خارجی که بتوانند Certificate های صادر شده برای کارکنان را شناسایی کنند. اگر می خواهید سایر سازمان ها بتوانند Certificate هایی که در سازمان شما به موجودیت ها داده می شود را شناسایی کنند ، شما می توانید در این حالت به جای استفاده از یک طراحی PKI داخلی ، از یک طراحی PKI جانبی و تجاری مثل VeriSign یا RSA یا GeoTrust استفاده کنید. علاوه بر این گزینه جانبی دیگری نیز وجود دارد که شما می توانید برای CA های خود Trust بین CA ها را ایجاد کنید.

 

  • استفاده از Certificate های صادر شده توسط CA های سازمان شما در سازمان های همکار ، ممکن است پرسنلی که در سازمان شما مشغول به کار هستند بخواهد اطلاعات یا امضاهای دیجیتال خود را که در سازمان شما استفاده می کنند را در یک سازمان همکار نیز مورد استفاده قرار دهند ، در این حالت شما می توانید یک Certificate دلخواه سازی شده یا Custom ایجاد کنید که نیازمندیهای سایر سازمان های همکار را نیز برطرف کند.


قوانین صنعتی و دولتی ، برخی از کشورها وجود دارند که قوانین خاصی برای طراحی ساختار سلسله مراتبی PKI و CA ها برای خود دارند. برای مثال کشور کانادا قانونی دارد که در آن نگهداری و حفاظت از اطلاعات شخصی افراد و مستندات الکترونیک که نمایانگر اطلاعات مشتری Certificate می باشد بایستی در شرکت بصورت کاملا محرمانه و حفاظت شده نگهداری شوند. این یعنی اینکه در صورت بروز مشکل برای اطلاعات شخصی افراد شرکت یا شخص مسئولی بایستی وجود داشته باشد که پاسخگوی این مشکل باشد و این اجبار در قالب یک قانون در طراحی های CA در کشور کانادا به اجرا در می آید.

Certificate ها برای اشخاص غیر خودی ( Non Personnel ) ، اگر شما برای افراد خارج از سازمان خود نیز قصد ارائه Certificate دارید ، می توانید به شکلی ساختار سلسله مراتبی CA های خود را طراحی کنید که در Certificate Policy جزئیات بیشتری در خصوص شیوه ارائه سرویس به مشتری های بیرونی لحاظ شده باشد.


 

ارزیابی نیازمندی های Active Directory


شما قبل از اینکه اقدام به نصب و راه اندازی یک Enterprise CA در محیط اکتیو دایرکتوری ویندوز سرور 2008 یا 2003 یا 2012 کنید بایستی یک سری آماده سازی های اولیه و همچنین نیازمندی ها را پیشبینی و انجام دهید ، این آماده سازی ها به شرح زیر می باشد:

  • تعیین تعداد Forest های موجود در محیط : تعداد Forest های موجود در مجموعه در تعداد Enterprise CA هایی که می خواهید در ساختار AD CS خود داشته باشید تاثیر مستقیمی دارد. یک Enterprise CA صرفا می تواند برای User ها و Computer هایی که در همان Forest وجود دارند Certificate صادر کند.اگر تعداد Forest های شما در مجموعه بیش از یکی است ، برای هر یک از Forest های خود در طراحی بایستی یک Enterprise CA را در نظر بگیرید.

 

  • تعیین تعداد Domain های موجود در محیط : اگر بیش از یک Domain در ساختار Forest شما وجود دارد ، یکی از مهمترین مسائل در طراحی ساختار PKI محل قرار دادن CA ها بر روی Domain مد نظر است .انتخاب Domain ای که میزبانی Computer Account های مربوط به CA را بر عهده داشته باشد تا حدود زیادی به این بستگی دارد که آیا مدیریت Domain های شما بصورت متمرکز انجام می شود و یا بصورت غیر متمرکز انجام می شود. در یک مدل مدیریت متمرکز معمولا CA ها در یک Domain قرار می گیرند ، در یک محیط با مدیریت غیر متمرکز شما ممکن است CA ها خود را بر روی چندین Domain قرار دهید.

 

  • تعیین عضویت گروه Local Administrators بر روی Member Server : اگر شما از CSP برای نگهداری Private Key مربوط به CA استفاده می کنید ، تمامی اعضای گروه Local Administrators ای که بر روی CA قرار دارند می توانند Private Key مربوط به CA را Export کنند.در این مواقع شما بایستی Domain یا OU ای که دارای کمترین و محدودترین تعداد Local Administrators می باشد را شناسایی کنید. برای مثال در سازمانی که دارای یک Forest خالی می باشد ، شما ممی توانید تمامی Enterprise CA های خود را در ساختار Forest بر روی Forest Root Domain ایجاد کنید که کمترین تعداد ممکن Local Administrator را دارد.

 

  • تعیین نسخه Schema موجود در Domain : برای پیاده سازی CA های ویندوز سرور 2008 و استفاده از تمامی امکاناتی که این CA در اختیار ما قرار می دهد شما بایستی آخرین نسخه از Active Directory Domain Services Schema را در اختیار داشته باشید. Schema در ویندوز سرور 2008 می تواند در Forest هایی که دارای دامین کنترلر های ویندوز سرور 2000 یا 2003 یا 2008 هستند پیاده سازی شود.

 


 

ارزیابی نیازمندی های Certificate Template


Certificate Template ها امکانی را فراهم می کنند تا شما بتوانید فرآیند ثبت نام Certificate یا Enrollment را در یک محیط مدیریت شده در Active Directory انجام دهید.با توجه به اینکه هر نسخه از محصولات ویندوز سروری که مایکروسافت ارائه کرده است دارای Certificate Template هایی با ویژگیها و نسخه های خاصی خود هستند ، مسئله هماهنگی یا Compatibility بایستی یکی از مسائلی باشد که در طراحی PKI بایستی در نظر بگیرید. اگر تاریخچه Certificate Template هایی که مایکروسافت ارائه داده است را بررسی کنیم ، میبینیم که در نسخه ویندوز سرور 2000 مایکروسافت تعداد 71 عدد Certificate Template ایستا و ثابت ارائه کرد ، در ویندوز سرور 2003 به Certificate Template ها قابلیت دلخواه سازی یا Customization را اضافه کرد و تعداد Certificate Template های خود را به 73 عدد اضافه کرد ، اما در ویندوز سرور 2008 ضمن اینکه مایکروسافت Certificate Template های نسبتا بیشتری ، نسبت به محصولات قبلی خود اضافه کرده بود امکانات بیشتری به این قابلیت در ساختار CA نیز اضافه کرده بود ، تعداد Certificate Template ها در ویندوز سرور 2008 به عدد 73 رسید.

به دلیل محدودیت ها و وابستگی هایی که مربوط به سیستم عامل می باشد ، Template های ویندوز سرور 2008 صرفا می تواند به CA هایی ارائه شوند که بر روی آنها ویندوز سرور 2008 نصب شده باشد . فقط کلاینت های ویندوز ویستا و سون و سرور 2008 می توانند برای ثبت نام هر 73 عدد Template ای که در ساختار PKI این سرور وجود دارد برای کامپیتورهای خود ثبت نام کنند. اگر تا به حال فقط 72 عدد از Template ها را در AD DS Forest نصب کرده اید ، بایستی Template های فعلی خود را بروز رسانی کرده و به جدید ترین تعداد که 73 عدد است ارتقاء دهید ، اگر هیچگونه Certificate Template ای در ساختار خود ندارید ، هر تعداد Template که تاکنون ایجاد شده است را می توانید در قسمت Configuration Container در AD DS Forest براحتی اضافه کنید.

نویسنده : محمد نصیری
منبع : انجمن حرفه ای های فناوری اطلاعات ایران

رفع مشکل پیام خطای Windows Cannot Load The User,s Profile

رفع مشکل پیام خطای Windows Cannot Load The User,s Profile  به روش زیر می باشد :

Click Start, click Run, type regedit, and then click OK. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory ManagementOn the Edit menu, point to New, and then click DWORD Value.
In the New Value #1 box, type PoolUsageMaximum, and then press ENTER.
Right-click PoolUsageMaximum, and then click Modify.
In the Value data box, type 60, click Decimal, and then click OK.
If the PagedPoolSize registry entry exists, go to step 8. If the PagedPoolSize registry entry does not exist, create it. To do this, follow these steps:
On the Edit menu, point to New, and then click DWORD Value.
In the New Value #1 box, type PagedPoolSize, and then press ENTER.
Right-click PagedPoolSize, and then click Modify.
In the Value data box, type ffffffff, and then click OK.
Exit Registry Editor, and then restart the computer

 

منبع:  http://www.tam-co.net 

dns records

DNS

تسلط بر مفاهیم دومین و تنظیمات DNS بخش مهمی از مدیریت سرور یا میزبانی هاستینگ را تشکیل می دهد. همچنین یک کاربر عادی از طریق آشنایی با این مفاهیم می تواند کنترل بیشتری بر عملکرد سایت خود و یا درخواست سرویس های مناسب از سرویس دهنده خود داشته باشد که باعث صرفه جویی در زمان و هزینه خواهد شد.
یک سرور DNS با یک فایل به نام Zone file برای هر دامنه تنظیم می شود که این فایل حاوی رکوردهای مرجع (resource records) می باشد. چندین نوع رکورد وجود دارند که مهمترین آنها به شرح زیر است:


- A : رکورد آدرس (Address record) باعث پیوند یک نام دامنه به یک آدرس IP می شود. به این معنا که اکنون آدرس آی پی و نام دامنه به یک چیز مشترک مثلا سایت شما اشاره دارند. اکنون سایت شما با آدرس آی پی و همچنین با نام دامنه قابل دسترسی است. این رکورد همچنین با عنوان DNS Record شناخته می شود.

- PTR : رکورد اشاره گر (Pointer Record) اطلاعات لازم برای Reverse DNS را فراهم می آورد که به منظور واقعه نگاری (Logging) و تطبیق (Verification) نام دامنه بکارگرفته می شود. همچنین با نام Inverse DNS شناخته می شود. PTR یک گزینه اختیاری است.

- CNAME : رکورد معیار نام (Canonucal Name Record) برای ایجاد نام های مستعار (Aliases) که به نام های دیگری اشاره می نماید بکار می رود. این گزینه معمولاً برای مرتبط کردن نامهای زیردامنه از نوع Mail , FTP , www به نام دامنه اصلی بکار می رود. مثلاً یک رکود CNAME می تواند www.YorDomain.com را به نام دامنه اصلی یعنی YorDomain.com مرتبط کند. بنابراین، عمل CNAME مر تبط با Aliasing names می باشد.

- NS : رکورد سرور نام دامنه (Name Server Record) یک DNS اصلی یا اولیه (Primary DNS) را برای یک نام دامنه مشخص می کتد. همچنین یک رکورد NS برای مشخص کردن یک DNS ثانویه یا Secondry DNS لازم است. دی ان اس ثانویه به عنوان سیستم کمکی یا اضافی (Redundancy) بطور دائم یک نسخه پشتیبان و بروز شونده از محتویات سرور دی ان اس اصلی را در خود نگهمیدارد.

- MX : رکورد انتقال یا تبادل نامه (Mail Exchange Record) برای معرفی کردن آدرس سروری بکار می رود که ایمیل ها باید بسوی آن منتقل شوند یا تغییر مسیر(Redirect) داشته باشند. این رکورد همچنین می تواند یک فیلد حق تقدم (Priority Field) داشته باشد بطوری که ایمیل بتواند از روی یک ترتیب تعیین شده به چندین سرور دیگر منتقل یا هدایت شود.

- TXT : رکورد متن یا Text Record می تواند برای اضافه کردن هر نوع توضیح بکار رود. این رکورد همچنین جهت فراهم کردن اطلاعات لازم برای سیستم تصدیق ایمیل SPF بکار رود.

- SOA : اولین رکورد در فایل یا رکورد شروع اعتبار (Start Of Authority) به عنوان اولین رکورد در فایل دی ان اس یا Zone File شناخته می شود که حاوی نام سرور دی ان اس اصلی می باشد. محتویات این رکورد باید با محتویات یک رکورد NS، آدرس ایمیل مدیر و طول زمانی که رکوردها باید پیش از بازگشت به سرور دی ان اس اصلی ذخیره شوند (Cash) مرتبط باشد

WSUS


 

WSUS مخففWindows Software Update Services  می باشد و بعنوان سرویسی برای به روز رسانی متمرکز کلاینت ها و سرور های ویندوزی به کار می رود. این نرم افزار نسخه بعدی و جایگزین نرم افزار SUS (Software Update Services) بوده و ابزاری برای مدیریت Update ها و وصله های ویندوز می باشد.

 

WSUS را می توان بر روی یک یا چند سرور برای بروز رسانی یک یا تعداد نامحدودی کلاینت نصب نمود. همچنین می توان WSUS را طوری تنظیم نمود که از مایکروسافت یا یک سرور WSUS دیگر حتی خارج از سازمان Update ها را دریافت کند.

WSUS امکانات دیگری را نیز ارائه می دهد :

- انتخاب Update خاص جهت اعمال روی کامپیوترها یا گروهی از آنها
- پشتیبانی از محصولات دیگر (مانند
Microsoft Office و ...)
- کاربران نمی توانند درخواست گرفتن
Update از سمت WSUS را رد نمایند در حالی که کاربرانی که از windows update site  استفاده می کنند می توانند در خواست Update را لغو نمایند
- ارائه گزارش کامل از وضعیت
Update کلاینت ها

WSUS Updates (وصله های بروز رسانی WSUS)

همان طور که در بالا اشاره شد، WSUS شما را قادر می سازد که Update ها را از Microsoft دانلود کرده و در بین کلاینت ها توزیع کنید. WSUS هیچ نوع پشتیبانی ای را در خصوص بروز رسانی ابزارهای غیر مایکروسافتی ارائه نمی دهد. برای مثال نرم افزار هایی که توسط شرکت های دیگر یا خودتان نوشته شده اند از طریق WSUS قابل به روز رسانی نیستند.

WSUS Database (بانک اطلاعاتی WSUS )

سرویس WSUS از بانک اطلاعاتی SQL که همگام با نصب WSUS نصب می شود استفاده می کند ولی بانک های اطلاعاتی SQL server یا MSDE را نیز پشتیبانی می کند.

هر سرور WSUS به یک بانک اطلاعاتی مجزا نیاز دارد و در بانک اطلاعاتی خود اطلاعات زیر را ذخیره می کند:

- اطلاعات تنظیمات سرور WSUS
- متا دیتا که شامل شرح هر
Update می باشد
- جزئیات اطلاعات کلاینت ها،
Update ها و وضعیت کلاینت ها در برابر Update ها

متا دیتا برای هر Update شرح آن، لیست فایل های مورد نیاز برای نصب و شرایط لایسنس (EULA) را شامل می شود. حجم متا دیتا بسیار کم است و معمولا از خود Update کوچکتر است و زمانی که شما سرور WSUS را با مایکروسافت همگام سازی می کنید دانلود می شود.

Client Targeting (هدف قرار دادن کلاینت)

یکی از قابلیت های کلیدی WSUS هدف قرار دادن Update ها برای گروه خاصی از کامپیوتر ها می باشد. WSUS به شما اجازه می دهد یک یا چند گروه هدف، مناسب با کامپیوتر های شبکه خود ایجاد کرده و سپس Update ها را برای هر گروه هدف و بطور مستقل نصب کنید. به صورت پیش فرض 2 گروه هدف All computers و Unassigned computers وجود دارد اما شما می توانید بر اساس نیاز خود گروه های متعددی ایجاد نمایید.

Update Approval (تایید Update)

WSUS امکاناتی را همراه نصب Update ها ارائه می دهد که شامل تنظیمات فوریت برای نصب یا پاک شدن Update می باشد.

سرور WSUS ابتدا متا دیتا را دانلود کرده و به ادمین اجازه می دهد که  یک Update را برای گروه یا کامیپوتری تایید نمایید، WSUS آن را از سروری که برای آن تنظیم شده است دانلود کرده و بر اساس درخواست شما به کامپیوتر های مشخص شده ارسال می نماید که WSUS Client آن را با استفاده از Windows Automatic Update Client  دانلود  و نصب می نماید.

زمانی که شما Update نهایی را برای نصب تایید کردید دانلود می شود.

Bandwidth Conservation (حفاظت از پهنای باند)

ممکن است در برخی موارد فایل Update جهت توزیع روی کلاینت ها حجیم بوده و پهنای باند زیادی از شبکه اشغال را کند برای مثال سرویس پک 2 ویندوز که بیش از 200 MB است، که در این موارد WSUS تلاش می کند برخورد دوستانه ای با پهنای باند داشته باشد. WSUS ابتدا متا دیتا که فایلی مستقل می باشد را دانلود کرده و تنها در زمانی که Update تایید شده آن را دانلود می کند.

IIS Consideration (نکات وب سرور)

به صورت پیش فرض WSUS در وب سایت پیش فرض در IIS نصب می گردد. در هنگام نصب WSUS به شما یک گزینه برای ایجاد وب سایت بر روی پورت دلخواه ارائه می شود و به شما این امکان را می دهد که تمام ترافیک WSUS را از یک پورت خاص عبور دهید این عمل برای سازمان هایی که فایروال های داخلی دارند بسیار مفید خواهد بود.

Mobile Client (کلاینت ها متحرک)

شما می توانید از طریق WSUS کلاینت های متحرک در شبکه را نیز Update نمایید

Requirements (پیش نیاز های پیاده سازی)

Windows 2003 server
-  
Microsoft IIS 6.0
-  
Microsoft .Net frame work 1.1
-  
Background Intelligent Transfer Service
-   1
GHz processor
-   1
GB RAM

پیش نیاز های نصب WSUS سرویس پک 2:

- ویندوز 2008 یا ویندوز 2003 سرور سرویس پک 1 و بالاتر
-
IIS 6.0 و بالاتر- مایکروسافت .Net Framework 2.0
Microsoft Management Console 3.0 -
Microsoft Report Viewer -
 
SQL Server 2005(در صورت عدم وجود SQL هنگام نصب یک Database داخلی ویندوز نصب می گردد)

بعد از آماده سازی پیش نیازها (نصب .Net Framework ، IIS و (Report Viewer  مراحل نصب WSUS را آغاز می کنیم. لازم به ذکر است این نرم افزار به طور رایگان از طریق سایت شرکت مایکروسافت قابل دانلود می باشد.
http://www.microsoft.com/downloads

مرحله اول: پس از اجرا کردن فایل نصب، در پنجره باز شده ورود شما به محیط نصب خوش آمد گویی می شود، بر روی گزینه next کلیک نمایید .

مرحله دوم: از شما نحوه نصب سوال می شود که شامل دو گزینه است:

1- Full server installation including Administration Consol: در این حالت سرویس WSUS به طور کامل و به همراه کنسول مدیریتی آن نصب می شود. در صورتی که سرور WSUS دیگری در سازمان ندارید این گزینه را انتخاب نمایید.2- Administration Consol only: در این حالت فقط کنسول مدیریتی WSUS نصب می شود. این گزینه در مواردی که سرور WSUS دیگر در سازمان نصب بوده و نیاز به مدیریت از روی سیستم دیگر باشد مورد استفاده قرار می گیرد.
گزینه اول را انتخاب و روی گزینه
Next کلیک نمایید.

مرحله سوم: در این بخش توضیحات مربوط به  License Agreement آمده است که گزینه I accept the terms of the License agreement  را انتخاب و بر روی گزینه Next کلیک نمایید.

مرحله چهارم: در این بخش مسیر ذخیره کردن Update ها باید مشخص شود که به صورت پیش فرض مسیر C:WSUS در نظر گرفته شده است. لازم به ذکر است که بعد از تایید Update ها برای نصب، کنسول اقدام به دانلود آن از سرور اصلی می نماید.

مرحله پنجم: این مرحله مربوط به  تنظیمات Database می باشد که شامل سه قسمت است:

1-  Install Windows Internal Database on this Computer: با انتخاب این گزینه یک Database  داخلی برای سیستم نصب می شود.
2- 
Use an existing Database Server on this Computer: در صورتی که بر روی سرور خود SQL دارید این گزینه را انتخاب نمایید.
3- 
Use an existing Database Server on a remote Computer: در صورتی که شما یک SQL در سازمان خود دارید می توانید در این گزینه آدرسی دهید نمایید.

مرحله ششم: در این بخش تنظیمات مربوط به IIS انجام می شود که شامل دو گزینه می باشد:

1-  Use the existing IIS default web site: این گزینه به صورت پیش فرض انتخاب و پیشنهاد می شود.2-  Create a Windows Server Update Services Web site: در صورتی که بخواهیم ترافیک عبوری WSUS را از پورت خاصی عبور دهیم از این گزینه استفاده می نماییم.
با انتخاب گزینه اول روی
Next کلیک نمایید.

مرحله هفتم: در این بخش گزارشی از تنظیمات که در مراحل نصب انجام دادیم نمایش داده می شود، برای ادامه روی گزینه Next  کلیک نمایید.

مرحله هشتم: صبر کنید تا سرویس بر روی سرور نصب گردد.

مرحله نهم: در این بخش پایان مراحل نصب اعلام می گردد، با انتخاب گزینه Finish آنرا تایید نمایید. 

تنظیمات اولیه کنسول مدیریتی WSUS:
بعد از تایید نهایی مراحل نصب بلافاصله صفحه
Configuration Wizard به نمایش در می آید که برای شروع کار با کنسول مدیریتی تنظیمات این بخش مورد نیاز بوده و شامل مراحل زیر می باشد:

مرحله اول: در این بخش قبل از شروع تنظیمات چند نکته ذکر شده است که حائز اهمیت می باشند

1-  آیا دسترسی کلاینت ها به این سرور از طریق فایروال تنظیم شده است؟
2-  آیا این سرور دسترسی به اینترنت یا سرور
Up Stream را دارد؟
3-  آیا کاربران شما در صورت نیاز اعتبار لازم برای دسترسی به
Proxy Server را دارند؟
بر روی گزینه
Next  کلیک نمایید.

مرحله دوم: در این مرحله مایکروسافت جهت همکاری با تیم توسعه نرم افزار خود، از شما دعوت می کند که مسائل و پیشنهادات خود را در جهت پیشرفت و ارائه نسخه های کامل تر و کاربردی تر این نرم افزار اعلام کنید. با زدن تیک پایین صفحه این بخش را تایید و بر روی گزینه Next کلیک نمایید.

مرحله سوم: این بخش مرتبط با تنظیمات Up Stream است که شامل دو گزینه زیر می باشد:

1-  Synchronize From Microsoft Update: با انتخاب این گزینه سرور بصورت مستقیم از مایکروسافت Update  دریافت می نماید.
2- 
Synchronize From another Windows Server Update Services: در صورتی که یک سرور WSUS دیگر در سازمان دارید می توانید از این گزینه استفاده نمایید.
گزینه اول را انتخاب و روی
Next کلیک نمایید.

مرحله چهارم: در این بخش تنظیمات مربوط به Proxy  نمایش داده می شود. در صورتی که در سازمان از Proxy استفاده می نمایید تنظیمات مربوطه را اعمال نموده و در غیر این صورت بر روی گزینه Next کلیک نمایید.

مرحله پنجم: این بخش اولین اتصال سرور WSUS به سرور Up Stream  می باشد. بر اساس تنظیماتی که تاکنون انجام دادیم سرور اطلاعات زیر را دانلود می نماید:

1-  لیست انواع مختلف Update که قابل دانلود می باشد.
2-  لیست محصولاتی که می توان برای آن ها
Update دریافت کرد.
3-  لیست زبان های موجود جهت دانلود.
روی گزینه
Start Connecting  کلیک نمایید.

مرحله ششم: در این بخش لیست زبان هایی که می توان Update آن ها را دریافت نمود مشاهده می شود. لازم به ذکر است اکثر زبان هایی که ویندوز پشتیبانی می نماید در این لیست وجود دارد.
با انتخاب زبان های مورد نظر بر روی گزینه
Next کلیک نمایید.

مرحله هفتم: در این بخش لیست محصولات مایکروسافت که قابلیت Update شدن از طریق WSUS را دارند مشاهده می کنید، که برخی از این محصولات شامل موارد زیر می باشد:

Visual Studio  ،  Exchange Server ، Forefront TMG ، ISA Server ، Security Essentials ، Office ، Silver Light ، SQL Server ، Windows
با انتخاب محصولات مورد نظر روی گزینه
Next کلیک نمایید.

مرحله هشتم: در این بخش لیست طبقه بندی محصولات ارائه شده نمایش داده می شوند که شامل موارد زیر می باشد:

Critical Update ، Definition Update ، Drivers ، Features Pack ، Security Update ، Service Pack ، Tools ، Updates Rollup و Updates .

مرحله نهم: این بخش مرتبط با زمان بندی دانلود Update ها می باشد که در چه بازه زمانی سرورآخرین Update ها را دانلود کند، که شامل دو قسمت دستی و اتوماتیک می باشد:
گزینه اتوماتیک را انتخاب و بر روی گزینه
Next  کلیک نمایید.

مرحله دهم: در این بخش تنظیمات WSUS پایان یافته، با کلیک بر روی گزینه Finish وارد کنسول مدیریتی آن شوید.

بعد از نصب و انجام تنظیمات باید تغییراتی را در کلاینت ها و سرور های خود جهت ارتباط با کنسول و دریافت Update ها انجام دهید. این تغییرات باید در Group Policy کلاینت ها و سرورها اعمال شوند، همچنین اعمال این تغییرات از طریق تنظیمات Active Directory  نیز امکان پذیر می باشد.

از طریق فرمان gpedit.msc وارد تنظیمات Group Policy شده و در مسیر زیر گزینه Configure Automatic Update را باز کرده و گزینه Enable  را فعال نمایید.

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update

در مسیر فوق نیز قسمت Specify Intranet Microsoft update service location را باز و گزینه Enable را فعال نمایید و همچنین نیاز است در قسمت Set the intranet update service for detecting updates  آدرس سرور WSUS وارد شود. (http//WSUS:8530)

کار با کنسول مدیریتی WSUS:
کنسول
WSUS دارای قسمت های اصلی زیر می باشد:

1-  Updates: در این بخش لیست Update ها و توضیحات مربوط به آن ها ارائه شده است و شما می توانید با انتخاب یک یا چند Update آن را بر روی یک کامپیوتر یا گروهی از کامپیوتر ها اعمال نمایید.

2-  Computers: در این بخش نیز یک گروه (Unassigned Computers) به عنوان پیش فرض در نظر گرفته شده است که تمامی کامیپوترهایی که با WSUS در ارتباط هستند در این گروه قرار دارند. شما می توانید براساس شبکه سازمان خود گروه های متعددی جهت اعمال Update ها ایجاد نمایید.

3-  Down Stream Servers: این بخش لیست سرورهایی است که سرور WSUS از آنها استفاده می کند.

4-  Synchronizations: در این بخش گزارشی از وضعیت زمان های سرور جهت گرفتن Update ارائه شده است.

5-  Reports: بخش Reports جهت گزارش گیری از کلاینت ها می باشد. که شامل 3 قسمت اصلی زیر است:

•  Update Report
•  Computer Report
•  Synchronizations Report

6-  Options: این بخش شامل تنظیماتی است که در Configuration Wizard  انجام دادیم، این تنظیمات قابل تغییر و ویرایش می باشند.

لازم به ذکر است در راستای این هدف، نرم افزارهای دیگری نظیر SCCM یا EPDP با امکانات بیشتر وجود دارند که مدیریت بروز رسانی Update ها،  تنها بخشی از قابلیت های این نرم افزار های جامع می باشد.

 

تنظیم سیستم کاربر:

اگر کاربر عضو دامین باشد از GPO دامین در غیر این صورت با استفاده ازGPO سیستم موارد زیر تنظیم می کنیم:

وارد Start>run>gpedit.msc

Computer configuration/administrative tem/windows component/windows update

به این مسیر رفته و تنظیمات زمان آپدیت گیری و آدرس آپدیت سرور و موارد دیگر به ترتیب انجام شود.

نکته : دستور WSUSUTIL.EXE جهت در اختیار داشتن منوی دستورات WSUS جهت مواردی مانند REINSTALL کردن UPDATE ها و ....

 

توصیه دیدن لینک http://forum.persiannetworks.com/f78/t29938.html  میباشد.

مشكل در پر بودن و ظرفيت remote desktop در ويندوز سرور

بعضا اتفاق افتاده است که هنگام ریموت کردن به ویندوز سرور خود متوجه میشوید تعداد session های login پر است زیرا ویندوز سرور همزمان به یک کاربر بصورت local و دو کاربر بصورت remote اجازه اتصال میدهد.حال اگر هنگام خروج log off نکنید session شما باز باقیمانده و اجازه ورود بصورت remote نخواهد داد.

برای حل مشکل ابتدا regedit خود را باز نمایید.سپس به نام dns  ویندوز سروری که مشکل شرح داده شده را دارد وصل شوید.سپس از مسیر زیر :

Hkeylocal-machine\system\current control set \terminal server 

وارد شوید.آنگاه از سمت راست مقدار کلید FdenyTSconnection را از 0 یعنی enable به 1 یعنی disable تغییر دهید.

Upgrading Windows 2003 to 2008:

Upgrading Windows 2003 to 2008:(با تشكر از دوست عزيزم مهندس بهروز رئيسي)

نکته مهم در این روش این است که در صورتی که Functional Level دامین native باشد حتما باید به 2003 تبدیل و یا به اصطلاح Raise گردد. در حالت کلی ویندوز در این روش پس از اجرای چند preparation tools می تواند upgrade شود.

1.       Functional Level Raising:

·         Domain Users and Computers را باز کنید.

·         بر روی نام Domain راست کلیک کنید و Raise Domain Functional Level را انتخاب کنید.

·         از  drop down menu دامین را به 2003 Raise کنید.

 

2.       Preparing Forest:

·         بر روی schema master با user ای که عضو یکی از گروه های Enterprise Admins ، Schema Admins ، Domain Admins باشدlog on  کنید.

·         محتویات فولدر \sources\adprep را از DVD Windows 2008 بر روی سرور کپی کنید.

·         Command prompt را باز کرده و به فولدر کپی شده navigate کنید و دستور زیر را وارد نمایید.

adprep /forestprep

·         منتظر پایان عملیات و دریافت پیام successful باشید.

 

3.       Domain Preparation:

·         بر روی infrastructure master با user ای که عضو گروه Domain Admins باشد log on کنید.

·         محتویات فولدر \sources\adprep را از DVD Windows 2008 بر روی سرور کپی کنید. (در صورتی که بر روی سرور موجود نباشد)

·         Command prompt را باز کرده و به فولدر کپی شده navigate کنید و دستور زیر را وارد نمایید.

adprep /domainprep /gpprep

·         منتظر پایان عملیات و دریافت پیام successful باشید.

·         حتما سرور پس از این مرحله reset شود.

 

4.       Windows 2008 installation:

·         با user ای با سطح دسترسی administrator برروی سرور log on کرده و DVD Windows 2008 را اجرا نمایید.

·         پس از طی مراحل اولیه گزینه Upgrade انتخاب شود.

·         ممکن است upgrade چند ساعت طول بکشد پس برای نصب صبر کنید.