DevOps לעומת DevSecOps: איך זה נראה בבנק אחד

הבנק מעביר את הפרויקטים שלו לקבלנים רבים. "חיצוניים" כותבים קוד, ואז מעבירים את התוצאות בצורה לא נוחה במיוחד. באופן ספציפי, התהליך נראה כך: הם מסרו פרויקט שעבר איתם בדיקות פונקציונליות, ולאחר מכן נבדק בתוך ההיקף הבנקאי לאינטגרציה, עומס וכו'. לעתים קרובות התגלה שהבדיקות נכשלו. ואז הכל חזר למפתח החיצוני. כפי שאתה יכול לנחש, פירוש הדבר היה זמני אספקה ​​ארוכים לתיקוני באגים.

הבנק החליט שניתן וצריך לגרור את כל הצינור תחת כנפו, מהתחייבויות ועד לשחרור. כך שהכל אחיד ובשליטה של ​​הצוותים האחראים על המוצר בבנק. כלומר, כאילו הקבלן החיצוני פשוט עובד איפשהו בחדר הסמוך של המשרד. על הערימה הארגונית. זהו devops רגיל.

מאיפה הגיע סק? אבטחת הבנק העמידה דרישות גבוהות איך קבלן חיצוני יכול לעבוד בגזרת הרשת, איזו גישה יש למישהו, איך ומי עובד עם הקוד. רק ש-IB עדיין לא ידע שכאשר קבלנים עובדים בחוץ, נהוגים מעט סטנדרטים בנקאיים. ואז בעוד כמה ימים כולם צריכים להתחיל להתבונן בהם.

הגילוי הפשוט שלקבלן גישה מלאה לקוד המוצר כבר הפך את עולמם.

ברגע זה התחיל הסיפור של DevSecOps, עליו אני רוצה לספר לכם.

אילו מסקנות מעשיות הסיק הבנק ממצב זה?

היו הרבה מחלוקת על העובדה שהכל נעשה בצורה לא נכונה. המפתחים אמרו שהאבטחה עסוקה רק בניסיון להפריע לפיתוח, והם, כמו שומרים, מנסים לאסור בלי לחשוב. בתורם, מומחי אבטחה היססו בין בחירה בין נקודות המבט: "מפתחים יוצרים נקודות תורפה במעגל שלנו" ו-"מפתחים לא יוצרים נקודות תורפה, אלא הם עצמם". המחלוקת הייתה נמשכת זמן רב אלמלא דרישות שוק חדשות והופעת פרדיגמת DevSecOps. אפשר היה להסביר שעצם האוטומציה הזו של תהליכים תוך התחשבות בדרישות אבטחת מידע "מחוץ לקופסה" תעזור לכולם להישאר מרוצים. במובן זה שהכללים נכתבים מיד ולא משתנים במהלך המשחק (אבטחת המידע לא תאסור משהו במפתיע), והמפתחים שומרים על אבטחת המידע על כל מה שקורה (אבטחת המידע לא נתקלת במשהו פתאום) . כל צוות אחראי גם לבטיחות האולטימטיבית, ולא כמה אחים מבוגרים מופשטים.

1. מכיוון שלעובדים חיצוניים יש כבר גישה לקוד ולמספר מערכות פנימיות, כנראה שניתן להסיר מהמסמכים את הדרישה "הפיתוח חייב להתבצע כולו על תשתית הבנק".
2. מצד שני, צריך לחזק את השליטה במתרחש.
3. הפשרה הייתה יצירת צוותים חוצי תפקודיים, שבהם העובדים עובדים בשיתוף פעולה הדוק עם אנשים חיצוניים. במקרה זה, עליך לוודא שהצוות עובד על כלים על שרתי הבנק. מההתחלה לסוף.

כלומר, ניתן להכניס לקבלנים, אבל צריך לתת להם מקטעים נפרדים. כדי שלא יכניסו איזשהו זיהום מבחוץ לתשתית הבנק וכדי שלא יראו יותר ממה שצריך. ובכן, כדי שהפעולות שלהם נרשמות. DLP להגנה מפני דליפות, כל זה נכלל.

באופן עקרוני, כל הבנקים מגיעים לזה במוקדם או במאוחר. כאן ירדנו על השביל והסכמנו על הדרישות לסביבות כאלה שבהן עובדים "חיצוניים". הופיע מגוון מרבי של כלי בקרת גישה, כלים לבדיקת פגיעות, ניתוח אנטי וירוס על מעגלים, מכלולים ובדיקות. זה נקרא DevSecOps.

פתאום התברר שאם לפני DevSecOps לאבטחה הבנקאית לא הייתה שליטה על מה שקורה בצד של המפתחים, אז בפרדיגמה החדשה האבטחה נשלטת באותו אופן כמו אירועים רגילים בתשתית. רק עכשיו יש התראות על הרכבות, שליטה בספריות וכו'.

כל שנותר הוא להעביר את הצוותים לדגם החדש. ובכן, צור את התשתית. אבל אלה זוטות, זה כמו לצייר ינשוף. למעשה, עזרנו בתשתית, ובאותה תקופה תהליכי הפיתוח השתנו.

מה השתנה

החלטנו ליישם את זה בצעדים קטנים, כי הבנו שהרבה תהליכים יתפרקו, וייתכן שהרבה "חיצוניים" לא יוכלו לעמוד בתנאי העבודה החדשים בפיקוח כולם.

ראשית, יצרנו צוותים צולבים ולמדנו לארגן פרויקטים תוך התחשבות בדרישות חדשות. במובן של ארגונית דנו באילו תהליכים. התוצאה הייתה תרשים של צינור ההרכבה עם כל האחראים.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• בדיקה: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
• מצגת (דיווח, תקשורת): Grafana, Kibana, Jira, Confluence, RocketChat.
• תפעול (תחזוקה, ניהול): Ansible, Zabbix, Prometheus, Elastic + Logstash, מנהל שירות MF, Jira, Confluence, MS Project.

ערימה שנבחרה:

• מאגר ידע - מפגש אטלסי;
• גשש משימות - אטלסיאן ג'ירה;
• מאגר חפצים - "Nexus";
• מערכת אינטגרציה רציפה - "Gitlab CI";
• מערכת ניתוח רציף - "SonarQube";
• מערכת ניתוח אבטחת יישומים - "Micro Focus Fortify";
• מערכת תקשורת - "GitLab Mattermost";
• מערכת ניהול תצורה - "Ansible";
• מערכת ניטור - "ELK", "TICK Stack" ("InfluxData").

הם התחילו ליצור צוות שיהיה מוכן לגרור קבלנים פנימה. יש הבנה שיש כמה דברים חשובים:

• הכל צריך להיות מאוחד, לפחות בעת העברת קוד. כי היו קבלנים רבים כמו שהיו כל כך הרבה תהליכי פיתוח שונים עם המוזרויות שלהם. היה צורך להתאים את כולם לאחד בערך, אבל עם אפשרויות.
• ישנם קבלנים רבים, ויצירה ידנית של תשתית אינה מתאימה. כל משימה חדשה צריכה להתחיל מהר מאוד - כלומר, יש לפרוס את המופע כמעט באופן מיידי כך שלמפתחים תהיה סט של פתרונות לניהול הצינור שלהם.

כדי לעשות את הצעד הראשון, היה צורך להבין מה נעשה. והיינו צריכים לקבוע איך להגיע לשם. התחלנו בכך שעזרנו לשרטט את הארכיטקטורה של פתרון היעד הן בתשתית והן באוטומציה של CI/CD. ואז התחלנו להרכיב את המסוע הזה. היינו צריכים תשתית אחת, זהה לכולם, שבה יפעלו אותם מסועים. הצענו אפשרויות עם חישובים, חשב הבנק, ואז החליט מה ייבנה ובאיזה כספים.

הבא הוא יצירת המעגל - התקנת תוכנה, תצורה. פיתוח סקריפטים לפריסה וניהול תשתיות. לאחר מכן מגיע המעבר לתמיכת מסועים.

החלטנו לבדוק הכל על הפיילוט. מעניין שבמהלך הפיילוט הופיעה ערימה מסוימת בבנק בפעם הראשונה. בין היתר הוצע בהיקף הפיילוט ספק מקומי של אחד הפתרונות להשקה מהירה. האבטחה הכירה אותו תוך כדי הטייס, וזה הותיר רושם בלתי נשכח. כשהחלטנו לעבור, למזלנו, הוחלפה שכבת התשתית בפתרון Nutanix, שכבר היה בבנק בעבר. יתרה מכך, לפני כן זה היה עבור VDI, אבל השתמשנו בו מחדש עבור שירותי תשתית. בהיקפים קטנים הוא לא השתלב במשק, אבל בהיקפים גדולים הוא הפך לסביבה מצוינת לפיתוח ובדיקה.

שאר הערימה פחות או יותר מוכרת לכולם. נעשה שימוש בכלי אוטומציה ב-Ansible, ומומחי אבטחה עבדו איתם בצמוד. מחסנית Atlassin שימשה את הבנק לפני הפרויקט. כלי אבטחה של Fortinet - זה הוצע על ידי אנשי האבטחה עצמם. מסגרת הבדיקה נוצרה על ידי הבנק, ללא שאלות. מערכת המאגר עוררה שאלות: הייתי צריך להתרגל אליה.

קבלנים קיבלו ערימה חדשה. הם נתנו לנו זמן לשכתב את זה עבור GitlabCI, ולהעביר את Jira למגזר הבנקאי, וכן הלאה.

צעד אחר צעד

שלב 1. ראשית, השתמשנו בפתרון של ספק מקומי, המוצר חובר למקטע רשת DSO חדש שנוצר. הפלטפורמה נבחרה בשל זמן האספקה ​​שלה, גמישות קנה המידה והאפשרות לאוטומציה מלאה. בדיקות שנעשו:

• אפשרות לניהול גמיש ואוטומטי לחלוטין של תשתית פלטפורמת הוירטואליזציה (רשת, תת-מערכת דיסק, תת-מערכת משאבי מחשוב).
• אוטומציה של ניהול מחזור חיים של מכונות וירטואליות (תבניות, תמונות, גיבויים).

לאחר ההתקנה והתצורה הבסיסית של הפלטפורמה, היא שימשה כנקודת הצבתם של תתי המערכות בשלב השני (כלי DSO, מתאר פיתוח מערכות קמעונאיות). נוצרו מערכי הצינורות הדרושים - יצירה, מחיקה, שינוי, גיבוי של מכונות וירטואליות. צינורות אלו שימשו כשלב ראשון בתהליך הפריסה.

התוצאה היא שהציוד המסופק אינו עומד בדרישות הבנק לביצועים וסובלנות תקלות. ה-DIT של הבנק החליט ליצור מתחם המבוסס על חבילת התוכנה Nutanix.

שלב 2. לקחנו את המחסנית שהוגדרה, וכתבנו סקריפטים אוטומטיים של התקנה ופוסט-קונפיגורציה לכל תת המערכות כך שהכל הועבר מהפיילוט למעגל היעד במהירות האפשרית. כל המערכות נפרסו בתצורה סובלנית לתקלות (כאשר יכולת זו אינה מוגבלת על ידי מדיניות הרישוי של הספק) וחוברו למדדים ולתת-מערכות לאיסוף אירועים. IB ניתחה את התאימות לדרישותיה ונתנה אור ירוק.

שלב 3. הגירה של כל תת המערכות וההגדרות שלהן ל-PAC החדש. סקריפטים לאוטומציה של תשתית נכתבו מחדש, וההגירה של תת-מערכות DSO הושלמה במצב אוטומטי לחלוטין. קווי המתאר של פיתוח IP נוצרו מחדש על ידי צינורות של צוותי הפיתוח.

שלב 4. אוטומציה של התקנת תוכנת אפליקציה. משימות אלו נקבעו על ידי ראשי הצוותים של הצוותים החדשים.

שלב 5. ניצול.

גישה מרחוק

צוותי הפיתוח ביקשו גמישות מרבית בעבודה עם המעגל, והדרישה לגישה מרחוק ממחשבים ניידים אישיים הועלתה כבר בתחילת הפרויקט. לבנק כבר הייתה גישה מרחוק, אבל זה לא התאים למפתחים. העובדה היא שהתוכנית השתמשה בחיבור של המשתמש ל-VDI מוגן. זה התאים למי שרק צריך דואר וחבילת אופיס במקום העבודה שלו. מפתחים יצטרכו לקוחות כבדים, ביצועים גבוהים, עם הרבה משאבים. וכמובן, הם היו צריכים להיות סטטיים, שכן אובדן סשן המשתמש עבור מי שעובד עם VStudio (למשל) או SDK אחר אינו מקובל. ארגון של מספר רב של VDI סטטי עבה עבור כל צוותי הפיתוח הגדיל מאוד את העלות של פתרון ה-VDI הקיים.

החלטנו לעבוד על גישה מרחוק ישירות למשאבי מגזר הפיתוח. Jira, Wiki, Gitlab, Nexus, בנייה ובדיקה של ספסלים, תשתית וירטואלית. מאבטחים דרשו שהגישה תינתן רק בכפוף לתנאים הבאים:

1. שימוש בטכנולוגיות שכבר זמינות בבנק.
2. התשתית לא צריכה להשתמש בבקרי תחום קיימים המאחסנים רשומות של אובייקטי חשבון פרודוקטיביים.
3. הגישה צריכה להיות מוגבלת רק למשאבים הנדרשים על ידי צוות ספציפי (כדי שצוות מוצר אחד לא יכול לגשת למשאבים של צוות אחר).
4. שליטה מרבית על RBAC במערכות.

כתוצאה מכך, נוצר דומיין נפרד עבור פלח זה. תחום זה הכיל את כל משאבי מגזרי הפיתוח, הן אישורי המשתמש והן תשתית. מחזור החיים של רשומות בתחום זה מנוהל באמצעות ה-IDM הקיים בבנק.

גישה ישירה מרחוק אורגנה על בסיס הציוד הקיים של הבנק. בקרת הגישה חולקה לקבוצות AD, שאליהן תאמו כללים על הקשרים (קבוצת מוצרים אחת = קבוצת כללים אחת).

ניהול תבניות VM

מהירות יצירת לולאת הרכבה ובדיקה היא אחד ה-KPIs העיקריים שנקבעו על ידי ראש יחידת הפיתוח, מכיוון שמהירות הכנת הסביבה משפיעה ישירות על זמן הביצוע הכולל של הצינור. נבחנו שתי אפשרויות להכנת תמונות VM בסיסיות. הראשון הוא גדלי התמונות המינימליים, ברירת מחדל לכל מוצרי המערכת, התאמה מקסימלית למדיניות הבנק לגבי הגדרות. השנייה היא תמונת הבסיס, המכילה POPPO כבד מותקן, שזמן ההתקנה שלו יכול להשפיע רבות על מהירות הביצוע של הצינור.

כמו כן, נלקחו בחשבון דרישות תשתית ואבטחה במהלך הפיתוח – שמירת תמונות עדכניות (פאצ'ים וכו'), אינטגרציה עם SIEM, הגדרות אבטחה לפי תקני הבנק.

כתוצאה מכך הוחלט להשתמש בתמונות מינימליות על מנת למזער את עלות שמירתן עדכניות. הרבה יותר קל לעדכן את מערכת ההפעלה הבסיסית מאשר לתקן כל תמונה עבור גרסאות חדשות של POPPO.

על סמך התוצאות גובשה רשימה של מערכות ההפעלה המינימליות הנדרשות, שעדכון שלהן מתבצע על ידי צוות התפעול, והסקריפטים מהצינור אחראים באופן מוחלט לעדכון התוכנה, ובמידת הצורך לשנות את הגרסה. של התוכנה המותקנת - פשוט העבירו את התג הנדרש לצינור. כן, זה מחייב את צוות המוצר של devops לקיים תרחישי פריסה מורכבים יותר, אבל זה מקצר מאוד את זמן התפעול הנדרש לתמיכה בתמונות בסיס, שאחרת עשויה לדרוש יותר ממאה תמונות VM בסיסיות לתחזוקה.

גישה לאינטרנט

אבן נגף נוספת עם אבטחת בנקאות הייתה גישה למשאבי אינטרנט מסביבת הפיתוח. יתר על כן, ניתן לחלק גישה זו לשתי קטגוריות:

1. גישה לתשתית.
2. גישה למפתחים.

הגישה לתשתית אורגנה על ידי העברת מאגרים חיצוניים באמצעות Nexus. כלומר, לא ניתנה גישה ישירה ממכונות וירטואליות. זה איפשר להגיע לפשרה עם אבטחת מידע, אשר הייתה נגד מתן כל גישה לעולם החיצון מגזרת הפיתוח.

מפתחים נזקקו לגישה לאינטרנט מסיבות ברורות (stackoverflow). ולמרות שלכל הפקודות, כאמור לעיל, הייתה גישה מרחוק למעגל, זה לא תמיד נוח כשאי אפשר לעשות ctrl+v ממקום העבודה של המפתח בבנק ב-IDE.

הושג הסכם עם IS כי בתחילה, בשלב הבדיקה, הגישה תינתן באמצעות פרוקסי בנקאי המבוסס על רשימה לבנה. עם השלמת הפרויקט, הגישה תועבר לרשימה השחורה. הוכנו טבלאות גישה ענקיות, שציינו את המשאבים והמאגרים העיקריים אליהם נדרשת גישה בתחילת הפרויקט. תיאום גישה אלו ארך זמן לא מבוטל, מה שאפשר להתעקש על המעבר המהיר ביותר לרשימות שחורות.

ממצאים

הפרויקט הסתיים לפני קצת פחות משנה. באופן מוזר, כל הקבלנים עברו למחסנית החדשה בזמן ואף אחד לא עזב בגלל האוטומציה החדשה. IB לא ממהרים לחלוק משוב חיובי, אבל גם לא מתלונן, שממנו אפשר להסיק שהם אוהבים את זה. הקונפליקטים שככו כי אבטחת המידע שוב מרגישה בשליטה, אך אינה מפריעה לתהליכי פיתוח. הצוותים קיבלו יותר אחריות, והיחס הכולל לאבטחת מידע השתפר. הבנק הבין שהמעבר ל-DevSecOps כמעט בלתי נמנע, ועשה זאת לדעתי בצורה העדינה והנכונה ביותר.

אלכסנדר שובין, אדריכל מערכת.

מקור: www.habr.com