در این مقاله ، رویکرد nice vpn به مدیریت پچ امنیتی برای زیرساخت هایی که وب سایت nice vpn را اجرا می کنند (نه سرورهای VPN) توضیح می دهد. به طور کلی ، رویکرد ما به امنیت این است:     هک کردن سیستم ها را بسیار دشوار کنید. در صورت هک شدن یک سیستم فرضی ، آسیب احتمالی را به حداقل برسانید و این واقعیت را تصدیق کنید که برخی از سیستم ها کاملاً ایمن نیستند. به طور معمول ، این مرحله در مرحله طراحی معماری شروع می شود ، جایی که ما دسترسی یک برنامه را به حداقل می رسانیم. مقدار زمانی را که یک سیستم می تواند به خطر بیفتد به حداقل برسانید. این نقاط را با توقیف منظم ، داخلی و خارجی اعتبار دهید. امنیت در فرهنگ ما ریشه دار است و دغدغه اصلی هدایت همه کارهای ما است. مباحث بسیاری دیگر مانند شیوه های توسعه نرم افزار امنیتی ما ، امنیت برنامه ها ، فرآیندهای کارکنان و آموزش و غیره وجود دارد ، اما موضوعاتی برای این پست محدود نیست. در اینجا نحوه دستیابی به موارد زیر را توضیح می دهیم: اطمینان حاصل کنید که کلیه سرورها بطور کامل وصله شده اند و بیش از ۲۴ ساعت از انتشار نشریات CVE پشتیبانی نمی کنند. اطمینان حاصل کنید که هیچ سرور بیش از ۲۴ ساعت استفاده نشده است ، بنابراین حد بالایی را برای مدت زمانی که یک مهاجم بتواند پایداری داشته باشد ، قرار دهید. ما هر دو هدف را از طریق یک سیستم خودکار انجام می دهیم که سرورها را با استفاده از سیستم عامل و همه جدیدترین نسخه ها شروع به بازسازی سرور می کند و حداقل هر ۲۴ ساعت یکبار آنها را از بین می برد. هدف ما از این مقاله این است که برای سایر توسعه دهندگان که با چالش های مشابه روبرو هستند مفید باشد و شفاف سازی در عملکرد nice vpn را به مشتریان و رسانه های خود ارائه دهیم. نحوه استفاده ما از کتابهای پخش و Cloudform از Ansible زیرساخت های وب nice vpn در AWS (بر خلاف سرورهای VPN ما که روی سخت افزار اختصاصی کار می کنند) میزبانی می شوند و ما از ویژگی های آن برای استفاده مجدد استفاده می کنیم. کل زیرساخت های وب ما با Cloudformation فراهم شده است ، و ما سعی می کنیم تا آنجا که می توانیم فرایندهای مختلف را به صورت خودکار انجام دهیم. با این حال ، به دلیل نیاز به تکرار ، خوانایی کلی ضعیف ، و محدودیت های نحوی JSON یا YAML ، می بینیم که کار با الگوهای Cloudformate خام بسیار ناخوشایند است. برای کاهش این مسئله ، ما از DSL به نام cloudform-ruby-dsl استفاده می کنیم که به ما امکان می دهد تعاریف الگو را در Ruby بنویسیم و قالب های Cloudformation را در JSON صادر کنیم.   به طور خاص ، DSL به ما اجازه می دهد تا اسکریپت های داده کاربر را به عنوان اسکریپت های منظم که به طور خودکار به JSON تبدیل می شوند بنویسیم (و فرایند دردناک ساخت هر خط از اسکریپت را به یک رشته JSON معتبر طی نکنیم). یک نقش عمومی مسؤولانه با نام cloudstruction-infrastruktur مراقبت می کند تا الگوی واقعی را به یک پرونده موقت تبدیل کند ، که در ادامه توسط ماژول Cloud Ansible استفاده می شود:

- name: 'render {{ component }} stack cloudformation json'
  shell: 'ruby "{{ template_name | default(component) }}.rb" expand --stack-name {{ stack }} --region {{ aws_region }} > {{ tempfile_path }}'
  args:
chdir: ../cloudformation/templates
  changed_when: false

- name: 'create/update {{ component }} stack'
  cloudformation:
stack_name: '{{ stack }}-{{ xv_env_name }}-{{ component }}'
state: present
region: '{{ aws_region }}'
template: '{{ tempfile_path }}'
template_parameters: '{{ template_parameters | default({}) }}'
stack_policy: '{{ stack_policy }}'
  register: cf_result

 

در playbook ، ما چندین بار با استفاده از متغیرهای مؤلفه مختلف ، نقش Cloudformation- زیرساختی را ایجاد می کنیم تا چندین پشته Cloudformation ایجاد کنیم. به عنوان مثال ، ما یک پشته شبکه داریم که VPC و منابع مرتبط را تعریف می کند و یک برنامه کاربردی که گروه Auto Scaling را تعریف می کند ، پیکربندی راه اندازی ، قلاب چرخه عمر و غیره را تعریف می کند.