در هنگام مطالعه مقالات امنیت در فناوری اطلاعات ، احتمالا بارها با واژه مواجه شده اید. در این مقاله قصد دارم تا توضیحاتی راجع به این اصطلاح بدم.

زیرساخت کلید عمومی (PKI) مجموعه‌ ای متشکل از سخت افزارها ، نرم‌افزارها، افراد، سیاست‌ها و دستورالعمل‌های مورد نیاز برای مدیریت، توزیع، استفاده، ذخیره و ابطال گواهی‌های دیجیتال است.

در رمزنگاری، PKI مقدمه‌ای است برای اتصال یک کلید عمومی به هویت کاربر، که با استفاده از یک مرکز صدور گواهی (CA) انجام می‌گیرد. هویت کاربر باید برای هر CA یکتا و قابل شناسایی باشد. نسبت دادن کلید عمومی به هویت افراد مطابق با یک روند ثبت و صدور انجام می‌شود، که بر اساس سطح تضمین لازم ممکن است توسط یک نرم‌افزار در مرکز صدور گواهی انجام شود و یا با نظارت انسان باشد.

زیر ساخت کلید عمومی ساده

گزینهٔ دیگر که با احراز هویت عمومی اطلاعات کلید عمومی سرو کار ندارد، زیر ساخت کلید عمومی ساده (SPKI) می‌باشد که حاصل ۳ تلاش مستقل برای غلبه بر پیچیدگی‌های X.509 و وب مورد اعتماد PGP می‌باشد. از آن جایی که کلید، تنها چیز قابل اعتماد به جای شخص می‌باشد، SPKI کاربران را با افراد وابسته نمی‌کند. SPKI از هیچ مفهوم اعتماد و اطمینان استفاده نمی‌کند، به طوری که تصدیق کننده، صادرکننده هم هست. این موضوع، در اصطلاحات SPKI “حلقهٔ احراز هویت” نامیده می‌شود، که در آن احراز هویت از طراحی اش جدایی ناپذیر است.

مطالعه مطلب

یکی از مهمترین تصمیمات مدیر پروژه و مدیر فنی در پروژه های نرم افزاری  قبل و در هنگام انجام پروژه انتخاب بسته های فن آوری ( Technology Stack ) است.اینکه برای قسمت های متفاوت نرم افزار از فریمورک واسط کاربری گرفته تا تکنولوژی های سمت سرور و … از چه مجموعه فن آوری هایی استفاده کنیم.هر تصمیمی در این مرحله می تواند در آینده محصول نقش اساسی را ایفا کند.

وضعیت محصولاتی که امروزه در حال استفاده از آن ها هستیم نتیجه تصمیماتی است که مدیران محصول در گذشته اتخاذ کرده اند

یک انتخاب درست معلول موارد زیادی است ، مهمترین نکته انتخاب تکنولوژی هایی است که تیم گسترش دهنده با آن آشنا باشد.استفاده از معماری های SPA به همراه AngularJS و RESTful API ها ممکن است بسیار هیجان انگیز و به روز به نظر برسند اما زمانی که تیم گسترش دهنده با آن آشنا نباشد احتمال شکست پروژه بسیار بالا می رود.

واسط کاربری (Front End)

یک تصمیم اساسی و بزرگ واسطه کاربری ای است که کاربران با آن سر و کار دارند و به مانند نمای ساختمان در جلب رضایت کاربران و افزایش تجربه کاربری موثر است.

مواردی مانند تطبیق پذیری با دستگاه ها ( Responsive بودن طراحی ) ، استفاده از فریمورک ها (مانند Bootstrap) و قابلیت شخصی سازی توسط کاربر از مواردی است که هنگام انتخاب یک فن آوری برای واسط کاربری باید در نظر گرفته شود.

پشت صحنه (Back End)

تابع انتخاب تکنولوژی ها برای پشت صحنه یک نرم افزار پارامترهای ورودی زیادی دارد ، میزان هزینه ، انطباق پذیری با اکو سیستم جاری ، میزان توسعه پذیری ، Scalability ، انتخاب معماری مناسب و …

در صورتی که تمام این موارد به طور دقیق و درست انتخاب شود به چشم کاربر نمی آید ولی زمانی که تنها یکی از موارد به اشتباه انتخاب شده باشد می تواند باعث عدم کارایی کل سامانه شود.

سوال هایی که قبل از انتخاب Technology Stack واسط کاربر باید از خود بپرسیم

  • مخاطبین پروژه چه کسانی با چه محدوده سن و دانش کامپیوتر خواهند بود
  • سرعت دسترسی کاربران به نرم افزار در چه حدی خواهد بود
  • آیا قابلیت Cross Browser بودن نرم افزارهای تحت وب اهمیت دارد؟
  • پشتیبانی از مرورگرهای قدیمی باید انجام گردد؟
  • قرار است کاربران از طریق چه دستگاه هایی ( دسکتاپ ، موبایل ، تبلت و … )  به سامانه متصل شوند
  • آیا در آینده نیاز به تغییر قالب نرم افزار است یا خیر
  • نرم افزار نیاز به شخصی سازی توسط کاربران دارد؟

سوال هایی که قبل از انتخاب Technology Stack مورد استفاده درBack End باید از خود بپرسیم

  • پلتفورم اصلی سازمان بر چه تکنولوژی ای استوار است؟ ( Windows , Linux , Unix , … )
  • پشتیبانی و نگهداری از نرم افزار توسط چه کسانی انجام خواهد شد؟
  • تیم گسترش دهنده نرم افزار با چه تکنولوژی ها و زبان های برنامه نویسی آشنا هستند؟
  • آیا برای انجام پروژه نیاز به کتابخانه های خاصی است که تنها در برخی از زبان ها موجود است؟
  • میزان تراکنش سیستم در روز / ساعت / هفته
  • میزان تراکنش های هم زمان
  • آیا نیاز به استفاده از کامپوننت های خاصی است؟
  • از بین سرعت ، امنیت و قابلیت نگهداری کدام یک برای ذی نفعان و صاحبان سامانه مهمتر است؟

جواب به تک تک این سوالات می تواند در فرآیند انتخاب تکنولوژی توسط مدیر محصول و مدیر پروژه یاری دهنده باشد.

مطالعه مطلب

به واسطه چند پروژه اخیر در داتیس ، مقالات زیادی را راجع به پیاده سازی امنیت در وب سرویس (SOAP) و سرویس های RESTful مطالعه کردم و تلاش کردم تا خلاصه مطالب رو در این پست بیارم.

قبل اینکه بخواهم راجع به اینکه امنیت در وب سرویس توضیحی بدم لازم دیدم تا راجع به این موضوع صحبت کنم که چرا اصلا WS-Security بوجود آمد.

اولین دلیل توانایی احراز هویت سرویس گیرنده ، امضا کردن و رمزنگاری پیام رد و بدل شده است.با این کار میشه مطمئن شد که سرویس گیرنده شناسایی مشخص هست ، داده ها در طول مسیر تغییر نکردند و کسی از محتوی پیام ها مطلع نمیشه.

برای محقق شدن این امکان ، امکانات پایه ای HTTP کافی نیستند ، هویت سنجی ، جامعیت و امنیت انتقال پیام ها چیزی بیش از رمزنگاری پیام منتقل شده است.برای حل این مشکلات استانداردهای WS-Security بوجود آمدند.

امنیت در وب سرویس ها شامل استانداردها و مشخصات از پیش تعریف شده است که این امر باعث میشه نیاز به پیاده سازی راهکاری ابتکاری برای ایجاد امنیت در سرویس های وب نباشه.

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

یکی از این استانداردها ، X.509 هست که برای مدیریت کلیدها و همچنین احراز هویت و رمزنگاری استفاده میشه.

احراز هویت:
انواع شیوه های احراز هویت کاربر در سرویس های وب به شرح زیر است:

  • Username/Password
  • PKI through X.509 Certificates
  • Kerberos

شیوه Username/Password
یکی از معمول ترین شیوه ها برای احراز هویت استفاده از شناسه کاربری و کلمه عبور است.این شیوه در HTTP Basic Authentication و Digest Authentication مورد استفاده قرار می گیره.نکته مهم اینه در صورتی که شما با HTTP Digest آشنا باشید استفاده از این شیوه احراز هویت بسیار آسان خواهد شد.برای ارسال مقدار اصالت سنجی در این شیوه ، استاندارد WS-Security المان UsernameToken را تعریف کرده.

<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordText">password</wsse:Password>
</wsse:UsernameToken>

در مثال زیر می توانید محتوی یک پیام اصالت سنجی را به صورت متن ساده مشاهده کنید.

<wsse:UsernameToken>
<wsse:Username>scott</wsse:Username>
<wsse:Password Type="wsse:PasswordDigest">
KE6QugOpkPyT3Eo0SEgT30W4Keg=</wsse:Password>
<wsse:Nonce>5uW4ABku/m6/S5rnE+L7vg==</wsse:Nonce>
<wsu:Created xmlns:wsu=
"http://schemas.xmlsoap.org/ws/2002/07/utility">
۲۰۰۲-۰۸-۱۹T00:44:02Z
</wsu:Created>
</wsse:UsernameToken>

این شیوه امن تر از راه حل های معمول است ، زیرا برای Hash کردن پسورد از الگوریتم هایی مانند MD5 و یا SHA-1 استفاده نمی کند.کلمه عبور با یک کد تصادفی و یک مقدار زمانی ترکیب شده است.

استفاده از X.509
روش دیگر برای احراز هویت کاربران استفاده از گواهی X.509 است.یک گواهی X.509 می تواند دقیقا به شما بگوید که کاربر سرویس گیرنده چه کسی است.با استفاده از PKI ، شما می توانید هر گواهی را به یک کاربر موجود در برنامه خود مطابقت دهید.با بکار گیری این شیوه اصالت سنجی  به راحتی می توانید از حمله Replay Attck جلوگیری کنید.

زمانی که پیامی به شیوه X.509 ارسال می گردد ، یک نگارش عمومی از گواهی WS-Security در المان BinarySecurityToken ارسال می گردد.این گواهی با استفاده از base64 کد شده و ارسال می گردد.در زیر یک نمونه درخواست به صورت متن ساده آمده است:

<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
Id="SecurityToken-f49bd662-59a0-401a-ab23-1aa12764184f"
>MIIHdjCCB...</wsse:BinarySecurityToken>
مطالعه مطلب

سال ها به تولید نرم افزارهای سازمانی پرداخته ام ، چه در نقش یک برنامه نویس ، چه در نقش تحلیلگر و طراح و چه در نقش مدیر پروژه.تجربیات بسیاری را از استادانم کسب کرده ام اما بسیاری دیگر را شکست هایم به من آموخته اند.شکست هایی که گاهی ضررهای مالی ، زمانی و حتی روحی قابل توجهی به مجموعه و شخص خودم وارد کردند.

اکنون به این نتیجه رسیده ام که یکی از عامل های موفقیت پروژه ها ، دوری از اشتباهاتی هست که منجر به شکست می شوند.چه در مقام یک برنامه نویس ساده باشید و چه مدیر پروژه ، راه کارهای زیر می تواند سهم بسیاری در افزایش احتمال موفقیت پروژه داشته باشد. خواندن ادامه چگونه یک مهندس نرم افزار موفق باشیم

مطالعه مطلب