עמוד: 1 מסך: 28 דפים 1-4 מ כ ר ז ל פ י ת ו ח ו ת ח ז ו ק ת א ת ר ה א י נ ט ר נ ט - פ ר ק י ם 2001396272 מ ס ' בקשה להצעות זו כוללת את הרכיבים הבאים: בנק שעות לפיתוח, לעיצוב, לתמיכה ותחזוקה תיעוד קוד מקור, מסמכים, נהלי התקנה מנהל פיתוח הדרכות העברת ידע לימוד קוד קיים ע"י המציע, שילוב צוות חח"י בפיתוח, העברת ידע לקוד
עמוד: 2 מסך: 28 דפים 4 תוכן העניינים: ) I ) יעדים 1 5 ) I ( לקוח / מומחה יישום 1.1 5 ) I ( יעדים ומטרות 1.2 5 ) I ( בעיות שהמערכת אמורה לפתור 1.3 5 ) I ( הקשר העסקי / ארגוני 1.4 5 ) I ( תכנית עבודה שנתית 1.5 5 1.6 תועלות צפויות ( I ) 6 1.7 אופק הזמן ( I ) 7 ) I ) יישום 2 7 7 7 7 7 8 8 פיתוח על בסיס חבילות מסירה (I) ) I ( אבטחת מידע ( I ) אבטחת מידע ( I ) התחייבות המציע בנושא אבטחת מידע )M( הסבר לעניין "סעיף מהותי" ( I ) כללי ( I ) איומי יחס ( I ) 2.1 2.19 2.19.0 2.19.0.2 2.19.0.3 2.19.1 2.19.2 9 10 10 10 10 11 11 12 14 ) הנחיות לפיתוח מאובטח )סעיף מהותי 2.19.3 ) תיעוד שדות קלט ומיפוי )סעיף מהותי 2.19.4 ) הצפנה )סעיף מהותי 2.19.5 ) שמירת לוג )סעיף מהותי 2.19.6 ) ניהול המערכת )סעיף מהותי 2.19.7 בסיס נתונים והגישה אליו )סעיף מהותי( 2.19.8 ניהול משתמשים, מדיניות סיסמאות, הרשאות וביקורת ( S ) 2.19.9 ) 2.19.10 תשלומים באתר באמצעות כרטיסי אשראי ( סעיף מהותי 2.19.11 על המציע להתייחס אל הגנה לפי מודל ) I ) STRIDE 15 2.21 נפחים עומסים וביצועים
עמוד: 3 מסך: 28 דפים 16 ) I ( טכנולוגיה 3 16 16 רכיבי חומרה רכיבי תוכנה 3.1 3.2 16 3.3 מערכת הפעלה 16 3.4 דפדפנים )S( 17 3.5 נגישות ( S ) 18 4 מימוש 18 18 18 18 18 20 20 21 21 22 גורמים מעורבים בחברת החשמל ( I ) תיאור כללי של המציע )M( הרכב הצוות מטעם המציע )S( צוות המציע )M( ידע וניסיון של המציע )S( נדרש צוות קבוע ( I ) מנהל הפיתוח מטעם המציע ( I ) ידע וניסיון של המציע ( S ) פרטים על קבלני המשנה ( S ) תכנית עבודה ( I ) 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4 23 4.5 תפעול שוטף ( S ) 23 ) S ( תיעוד 4.6 24 שירות ( S ) 4.7 ותחזוקה 25 26 השתלבות בארגון הנעת המערכת ( S ) חוסן ואמינות ( S ) 4.8 4.9 27 נספחים
עמוד: 4 מסך: 28 דפים ) I. 1 יעדים ) לחברת החשמל )"החברה"( אתר אינטרנט שכתובתו: https://www.iec.c.il ואפליקצית סמארטפון בחנויות: אפסטור וגוגל פליי המתויגות בשם "חברת החשמל". מספר שירותים נפוצים באתר האינטרנט הותאמו לפלטפורמות ניידות ומהווים את "האתר המותאם". אתר האינטרנט, האתר המותאם והאפליקציה של החברה, יקראו להלן במסמך זה : "הערוצים הדיגיטליים של החברה". מטרת מסמך זה, היא להגדיר את הדרישות להמשך פיתוח ותחזוקת הערוצים הדיגיטליים של החברה, על כל היישומים אשר יוגדרו על ידה, תוך עמידה בדרישות ובתכולת מפרט זה. הגדרות: מונח פרויקט מנהלי ועורכי תוכן, משתמשים לקוחות גולשים פורטל אינטרנט ציבורי רב-ערוציות הסבר אוסף פעילויות שעל המציע הזוכה לבצע במסגרת תכולה המוגדרת במפרט זה עובדי חברה האמונים על התוכן באתר האינטרנט ובעלי הרשאה להוסיף, לעדכן ולמחוק תוכן, עפ"י מידור אזורי תוכן ייעודיים ארגונים, חברות ואנשים בארץ ובעולם שיש להם אינטראקציה כלשהי עם החברה כלל הציבור בארץ ובעולם הניגש לערוצים הדיגיטליים של החברה לקבלת מידע או שירות אתר אינטרנט המספק מידע ושירותים מותאמים לכלל הציבור. השירותים מסופקים הן על-ידי החברה והן על-ידי ספקי שירות אחרים מרשת האינטרנט, כגון: מפות, מזג אוויר, שערי מטבע, חנויות וכד' לקוח פונה לארגון בערוץ דיגיטלי של החברה שבו נוח לו ברגע מסוים, ובנוגע לאותה פניה. לקוח יכול להתחיל את פניה באמצעות ערוץ אחד, להמשיך את הטיפול בערוץ שני, לסיימו בערוץ שלישי ולסגירת מעגל הטיפול לקבל הודעת SMS לטלפון הנייד המאשר את ביצוע הפעולה. את כל הפעולות הללו הלקוח יוכל לבצע ממיקומים שונים. מבחינת הלקוח, מדובר בפניה אחת, והוא מצפה שהחברה תזהה אותו, תדע מה הצרכים שלו באותו רגע ותספק לו מענה מהיר ואפקטיבי.,Applicatin Prgramming Interface ממשק תכנות יישומים, המגדיר את הדרכים שבהם תוכנית היישום רשאית לבקש שירות מספריות ו / או מערכות הפעלה שיטה איטרטיבית ואבולוציונית לפיתוח תוכנה, השמה דגש על יכולת התגובה לשינוי, יעילות ואיכות. כל איטרציה היא כמו פרויקט תכנות זעיר, הכוללת את כל המשימות הנדרשות על מנת להפוך את הפרויקט לפונקציונאלי: תכנון, ניתוח דרישות, איפיון, פיתוח, בדיקות, ותיעוד, אשר בסיומו מכוון לשחרר תוכנה חדשה API פיתוח agile
עמוד: 5 מסך: 28 דפים.1.1 לקוח / מומחה יישום ( I ) הלקוחות: ארגונים, חברות ואנשים בארץ ובעולם שיש להם אינטראקציה כלשהי עם החברה. מומחה היישום: יו"ר מינהלת אתר האינטרנט, סמנכ"ל רגולציה, קשרי ממשל ותקשורת. מנהלי ועורכי התוכן..1.2 יעדים ומטרות ( I ) קיצור וייעול תהליכים עסקיים תוך שיפור השירות ללקוח. המשך פיתוח אתר האינטרנט והערוצים הדיגיטליים כחלק מתפישת רב-ערוציות ושמירה על רצף תהליכי ותפעולי מול לקוחות החברה וגורמים נוספים. ערוצים עוקפי תור, אשר יסיטו לקוחות מפנייה טלפונית למרכזי השירות. אמינות וביצועים גבוהים. שירות עצמי וחווית משתמש אינטראקטיבית ומושכת. פיתוח אתר אינטרנט, המותאם לפלטפורמות ניידות ללא שכפול קוד. אינטגרציה עם מוצרי צד ג' לנושא רב-ערוציות ונגישות. 1.3. בעיות שהמערכת אמורה לפתור ( I ) פיתוח דואלי - אתר אינטרנט ואתר מותאם לפלטפורמות ניידות. פיתוח גנרי אשר יתאים לשימוש חוזר..1.4 הקשר העסקי / ארגוני ( I ) נושא הרב-ערוציות הוכר על-ידי מנכ"ל החברה כנושא אסטרטגי, שמטרתו להתוות מדיניות ארגונית לאינטראקציה בין החברה לבין לקוחותיה. המדיניות תהווה חזון הכולל יריעה רחבה של הפעילות העסקית של החברה, במטרה למנף פעילות זו, להגדיל נתח שוק בארץ ובחו"ל, להביא לחסכון בעלויות ולהסטת מרכז הכובד מפניות למוקדי שירות לשימוש בערוצים הדיגיטליים של החברה, לשיפור איכות השירות ולשביעות רצון הלקוחות. הערוצים הדיגיטליים כוללים את אתר האינטרנט, האתר המותאם לפלטפורמות ניידות, אפליקצית חברת החשמל הרשתות החברתיות ועוד. הערוצים "ידברו" ביניהם ויאפשרו ללקוחות שמירה על רצף תהליכי ותפעולי ללא קשר מאיזה ערוץ התחילו את התהליך..1.5 תכנית עבודה שנתית ( I ) ביצוע הפרויקט ישתלב בתכניות העבודה של החברה לשנים 2016-2018. 1.6 תועלות צפויות ( I ) שיפור תדמיתי חסכון בעלויות ע"י הפחתה בשיחות טלפון / עלייה בשימוש בשירותי הדיגיטל
עמוד: 6 מסך: 28 דפים קיצור זמן פיתוח שיפור איכות תוכנה קיצור תהליכים עסקיים הרחבת סל שירותים בעלי ערך מוסף ללקוח שיפור חווית המשתמש קידום במנועי חיפוש המשך הנגשה לבעלי מוגבלויות בהתאם לדרישות החוק ניהול נכון של אתר מרובה שפות ייעול עבודת עורכי התוכן תמיכה בדרישות אבטחת המידע שימוש במכשירים ניידים ) I ( 1.7 אופק הזמן תקופת ההתקשרות: שנתיים + אופציה לשנה נוספת. )ראו התייחסות גם בסעיף 0.3.7 בפרק המנהלה " תקופת ההתקשרות ואופציות"(. טבלה - 1 לו"ז נדרש: 1.0.0 אבני דרך/פעילויות לימוד הקוד הקיים ע"י המציע הדרכות Sharepint והכרת היישום לצוות הפיתוח של חח"י בנק שעות: פיתוח - התקנת קוד מקור בחח"י - עיצוב - תחזוקה - תיעוד: מסירת תיעוד מלא בשפה העברית מסירת נהלי התקנה העברת ידע לצוות הפיתוח בחח"י אופק הזמן מרגע חתימת החוזה ובתוך 30 ימי עבודה בתיאום עם מנהל הפרויקט בחח"י מרגע חתימת החוזה ולאורך כל תקופת התקשרות הבסיס והאופציה התקנת קוד מקור בחח"י תתבצע ע"י הספק בכל התקנת חבילת קוד עד תום תקופת החוזה תיעוד מערכת ימסר לפני פיתוח המערכת נהלי התקנה ימסרו לפני כל התקנה עם סיום ההדרכות ועד תום תקופת ההתקשרות אחריות המציע הזוכה המציע הזוכה -המציע הזוכה -הלו"ז יקבע ע"י מנהל הפרויקט מטעם חח"י והתוצר הסופי יאושר על ידו - המציע הזוכה -התקנה ופיתוח באישור מנהל הפרויקט מטעם חח"י המציע הזוכה
עמוד: 7 מסך: 28 דפים ) I. 2 י י ש ו ם ) הערוצים הדיגיטליים של החברה מהווים פלטפורמה תקשורתית להעברת מידע, ומאפשרים ללקוח קבלת שירות וביצוע פעולות עסקיות באופן עצמאי, ללא צורך בהגעה למשרדי החברה או המתנה לנציגי שירות. מתוקף היותם ערוצים "עוקפי תור", הם כוללים אזור אישי, בו ניתן לקבל מידע אישי או לבצע פעולות לאחר הזדהות. בעוד אתר האינטרנט מוכוון קהלי יעד, כגון: לקוחות ביתיים, לקוחות עסקיים, יזמים, משקיעים, חשמלאים וכדומה, האפליקציה מוכוונת שירות ללקוחות ומכילה מידע חיוני לציבור בעיקר בנושא מידע על תקלות באספקת החשמל, דיווח על מיפגע ומידע אודות הפסקות מתוכננות והפסקות בפועל בעת חירום חשמלי. ( I ). 2.1 פ י ת ו ח ע ל ב ס י ס ח ב י ל ו ת מ ס י ר ה המשך פיתוח הערוצים הדיגיטליים, הקיימים של החברה, יתבצע על ידי המציע הזוכה ובאחריותו ובשילוב צוות הפיתוח של החברה, תוך ליווי צמוד של המציע הזוכה. השירות הנדרש יינתן על בסיס חבילות מסירה, לפי שעות עבודה. 2.2 2.18 2.19 לא רלבנטי אבטחת מידע ) I ( ( 2.19.0 I ) 2.19.0.1 חברת חשמל לישראל מחוייבת לעמוד בדרישות אבטחת מידע של הרשות לאבטחת מידע )רא"מ(. בכל מקרה של אי התאמה בין דרישות אבטחת מידע לבין האפיון - שיקול אבטחת מידע גובר על האיפיון. על המציע הזוכה למצוא את הפתרון. בדיקות אבטחת מידע יבוצעו על-ידי המציע הזוכה ובתיאום עם החברה ויכללו בדיקות שונות לרבות התקפות יזומות. אי עמידה בדרישות אבטחת המידע עלולה לגרור הפסקת פעילות לרבות במצב ייצור. ( 2.19.0.2 M ) התחייבות המציע בנושא אבטחת מידע המציע מתחייב לעמוד בדרישות הבאות הכלולות בסעיף אבטחת מידע, המסומנות כ"סעיף מהותי", במידה ויזכה במכרז. הסבר: לעניין "סעיף מהותי" ראו תת הסעיף הבא. ) I ( חלק מהדרישות שלהלן בסעיף "אבטחת מידע" סומנו בסימון מיוחד ליד כותרתן :"סעיף מהותי". המשמעות היא שעמידה באותן דרישות ע"י הספק הזוכה הינה ברמת חשיבות מאד גבוהה ואף קריטית מבחינת חברת החשמל. אי עמידה באותן דרישות ע"י הספק הזוכה במכרז זה, במהלך תקופת ההתקשרות, תהווה הפרה יסודית )הפרה ע"י הספק הזוכה( של ההזמנה/החוזה שייחתם בעקבות מכרז זה, אשר תקנה לחברה את הסעדים המוגדרים בחוזה ובדין, ובנוסף תקנה לחברה, במצטבר: א. זכות סיום של החוזה תוך שבוע מיום ההפרה, אם לא תוקנה ההפרה ע"י הספק הזוכה. 2.19.03
עמוד: 8 מסך: 28 דפים ב. פיצוי מוסכם בו יחוב הספק כלפי החברה, ללא דרישה להוכחת נזק מצד החברה.)פירוט הפיצוי מפורט בחוזה(. הפרה ו/או אי עמידה ביתר הדרישות וההוראות שבסעיף "אבטחת מידע" שלא סומנו כסעיפים מהותיים, ייחשבו כהפרה רגילה )לא מהותית( של החוזה ע"י הספק, שבגינם יעמדו לחברה סעדים בהתאם לחוזה ועפ"י הדין. בנוסף, ראו התייחסות בסעיף 5 בשלד החוזה המצורף למסמכי המכרז. 2.19.1 כללי ( I ) מטרתו של אתר האינטרנט של החברה הינה מתן מענה לשלושה צרכים: חלק ממערך ההסברה של חח"י. מקור מידע רשמי, אמין ועדכני של נתונים, פרסומים והודעות לציבור. שירותים מקוונים לציבור: מידע אישי. נתוני צריכת חשמל. תשלומים מקוונים. מתן הצעות ספקים. הגשת מועמדות להעסקה. חולשת אבטחה עלולה לאפשר השתלטות על מערכת, ולהשתמש בה להמשך התקפות לתוך רשת האירוח. אכיפת מדיניות אבטחת המידע מתבצעת כחלק מהפעילות השוטפת עקב ההיסטוריה של התקפות על אתרי אינטרנט בעולם ובארץ, ולפיכך האתר כפוף למדיניות אבטחת מידע נוקשה. הקפדה על תכנות נכון, בהתאם לתקני אבטחה מהווה תנאי הכרחי ביישום המדיניות. עקרונות אבטחת המידע נקבעו ואושרו ע"י צוות אבטחת מידע ולוחמת רשת )סייבר( של החברה. איומי יחס ( I ) עיקר האיומים מחולקים לשלוש רמות: פגיעויות מערכת הפעלה לרבות פגמי אבטחה, שימוש בשירותים אסורים, תוכנות לא מורשות, הרשאות לקויות וכיו"ב. פגיעויות ברשת תקשורת כגון שימוש בפרוטוקולים אסורים, חיבור רשתות, וכד'. כולל עיבוד שגוי של קלט משתמש, העדר בקרה על פלט, פגיעויות היישום ועוד. הרשאות לקויות סכנות ואיומים נפוצים על יישומי אינטרנט מפורטים בנספח 1 סעיף )1( שיטות פעולה של תוקפים מפורטות בנספח 1 סעיף )2( 2.19.2
עמוד: 9 מסך: 28 דפים הנחיות לפיתוח מאובטח )סעיף מהותי( על המציע הזוכה לפעול על-פי ההנחיות המפורטות להלן: 2.19.3.1 שיתוף צוות אבטחת מידע ולוחמת רשת )סייבר( של חח"י משלב האפיון, ולאורך כל תהליך הפיתוח, העברה לייצור, תחזוקה. 2.19.3.2 2.19.3.3 2.19.3.4 2.19.3.5 2.19.3.6 2.19.3.7 2.19.3.8 2.19.3.9 2.19.3.10 בסיום שלב התכנון ביצוע security design review על-ידי גורמי יחידת אבטחת מידע ולוחמת רשת )סייבר( של חח"י או מי מטעמה. המערכת חייבת לפעול תחת ההגבלות וההקשחות של אבטחת מידע. המציע יפתח את המערכת תוך התחשבות בהקשחות של סביבת ייצור. לא יתאפשרו שינויי הרשאות ברמת התשתיות. המציע יפתח את המערכת על-פי עקרון הרשאות מינימליות לצורך מניעת אי תפקוד של המערכת בסביבת הייצור המוקשחת. יש להשתמש ב- POST בשליחת נתונים מתבניות. אין ליזום התקשרות מהשרת אל מחוץ לרשת למעט המקרים הבאים: שליחת הודעות בדוא"ל באמצעות פרוטוקול SMTP מול שרתים מורשים בלבד. שליחת מסרונים באמצעות שרת פנימי / ספק מורשה. וידוא תעודה דיגיטלית אל מול רשות אשר הנפיקה תעודה זו. חלה חובה להגדיר מנגנון לכידה וטיפול בשגיאות. בשום מקרה לא יוצג מידע אודות מהות התקלה אלא דף שגיאה כללי בלבד לרבות דף שגיאה כללי המופק על ידי מערכת הגנה.WAF רכיב קריטי של המערכת הינו הגנה על פרמטרים ואכיפת האותנטיות שלהם. שינוי פרמטרים שמועברים לשרת הינה תופעה נפוצה, אין להניח דבר על קלט זה. אין להשתמש בערכים שהתקבלו ישירות מהמשתמש לצורך יצירת דפים דינאמיים. חלה חובה על ביצוע בדיקות סינון ואימות הקלט הן בצד הלקוח והן בצד השרת, לרבות: בדיקת הפורמט והתצורה. כמות התווים / נפח נתונים בקלט. סינון תווים אסורים או לא תואמים את סוג הפרמטר. סינון ע"י שימוש ב- WhiteLists ו- Expressin Regular בטרם הכנסת נתוני הקלט אל היישום. יש לצמצם אפשרות קלט חופשי ולהעדיף שימוש בתפריטים או תבניות. בכל מקרה חובה לבצע סינון של מידע מהקלט החופשי )ע"פ סעיפים לעיל(. יש להסיר כל הערות ותיעוד פיתוחי מהגרסה העולה לייצור. חל איסור להסתמך על מידע שמגיע מהמשתמשים לרבות נתונים שלא אמורים להיות מוזנים על ידם דוגמת עוגיות.)Ckies( 2.19.3
עמוד: 10 מסך: 28 דפים 2.19.3.11 יש לבצע ווידואי פלט בטרם בניית התצוגה. אין לספק שום מידע פרט לזה שצריך להתפרסם. תחזוקת ה- Sessin אזורים פרטיים באפליקציה יזוהו עם.Sessin identifier Sessin identifier יוצפן ויהיה חתום ובעל חותמת זמן על מנת למנוע גניבת זהות ועקיפת שלב ההזדהות. חוסר פעילות Sessin לא פעיל במשך 30 דקות יסתיים לאלתר. Sessin פעיל לא יארך מעבר לזמן מרבי של 2 שעות. יש לאפשר למשתמש סיום.LgOff על ידי יצירת פעולת sessin סגירת האפליקציה על ידי המשתמש )סגירת דפדפן( יש לסיים את ה- sessin באופן מידי. בכל מקרה שזוהתה שגיאת אבטחה באפליקציה, יש לסיים את ה- sessin באופן מידי. הזרקת סקריפטים וקוד המתקבל מהמשתמש. תחסם אפשרות קבלת קוד מהמשתמש, לפי הכללים הבאים: קביעת קידוד דף אחיד. קידוד ל HTML לקלט המוצגים למשתמש. 2.19.4 תיעוד שדות קלט ומיפוי )סעיף מהותי( הספק יצרף תיעוד מלא על כל עמוד שבו שדות קלט גלויים ונסתרים. בתיעוד ימופו כל שדות הקלט ויתואר סוג הנתון, ערכים מותרים )אורך קלט, תווים מורשים(. 2.19.5 הצפנה )סעיף מהותי( 2.19.5.1 פעולת ההצפנה תתבצע בצד השרת ולא בצד הלקוח. 2.19.5.2 2.19.5.3 2.19.5.4 2.19.5.5 2.19.5.6 2.19.6 זרם המידע עבור אזורים חסויים יוצפן בשימוש ב- TLS גרסה 1.0 לפחות. במקרים מסוימים יש להצפין ברמת האפליקציה נתונים קריטיים. יש להשתמש במנגנוני הצפנה מובנים כגון:.RSA,AES יש להצפין נתונים כגון: שם משתמש וסיסמא,.Sessin Identifier קבצי תצורה יוצפנו Cnnectin string מול בסיס הנתונים וכו'. שמירת לוג )סעיף מהותי( 2.19.6.1 המערכת תשמור לוג אפליקטיבי אודות פעולות המשתמשים. 2.19.6.2 הלוג יכלול לפחות שם המשתמש, כתובת,IP תאריך/שעה ופעולה אשר ביצע. 2.19.6.3 נוסף לעיל הלוג יכלול שגיאות חריגות אשר התבצעו במהלך הריצה. 2.19.6.4 לא ישמר בלוגים מידע רגיש )כגון סיסמאות. ת.ז., פרטי תשלום וכו' (. 2.19.7 ניהול המערכת )סעיף מהותי( ממשק ניהול יש להפרידו לגמרי מחלק האתר המוצג לגולשים. המציע יפעל על פי ההנחיות המפורטות בנספח 1 סעיף )3( וסעיף )4(.
עמוד: 11 מסך: 28 דפים 2.19.8 בסיס נתונים והגישה אליו )סעיף מהותי( 2.19.8.1 שרת בסיס הנתונים יהיה נפרד לחלוטין משרתי ה- Web. 2.19.8.2 השרת יכלול אך ורק מידע ציבורי. 2.19.8.3 לא תתאפשר גישה לבסיס הנתונים מהיישום באמצעות חשבון אדמיניסטרטור 2.19.8.4 2.19.8.5 2.19.8.6 2.19.8.7."sysadmin" או אחר בעל רמת גישה )sa( המשתמש, אשר ישמש לגישה יהיה בעל הרשאות הנמוכות ככל האפשר, ללא הרשאות מחיקה delete( )drp, וכדומה. נתוני משתמשים רגישים כגון סיסמאות יוצפנו ב- Hash )סוג.)sha-2 אין הרשאות גורפות בבסיס נתונים. הרשאות כתיבה או מחיקה מאופשרות נקודתית. אין להשתמש בשאילתות דינאמיות. הספק יוודא שלא קיימות שאילתות דינמיות בקוד. 2.19.9 ניהול משתמשים, מדיניות סיסמאות, הרשאות וביקורת ( S ) המציע יפרט את יכולתו לעמוד בכל אחד מתתי הסעיפים הבאים: 2.19.9.1 בתהליך הרישום של משתמש יש לחולל שם משתמש ייעודי ואין להשתמש בנתונים אישיים כגון שם פרטי, שם משפחה, תעודת זהות, חשבון דוא"ל. 2.19.9.2 2.19.9.3 2.19.9.4 2.19.9.5 2.19.9.6 2.19.9.7 2.19.9.8 בתהליך רישום חלה חובה להשתמש במנגנון CAPTCHA לצורך מניעת מתקפת מניעת שירות )DOS( על ידי ניסיונות מרובים של יצירת משתמש )כולל כושלים( אוטומטיים וידניים. לאחר 3 ניסיונות כושלים יש לסגור ה- sessin, במקביל יש לרשום אירוע בלוג בשילוב כתובת ה- IP לצורך התראה למוקד.SOC שיחזור שם משתמש היה ואין ברשות הלקוח את שם המשתמש, עליו להזין בעמוד המיועד לכך את כתובת הדוא"ל הרשומה במערכת או מספר טלפון נייד בצירוף.CAPTCHA שם משתמש ישלח אל כתובת הדוא"ל או באמצעות הודעת SMS אל הטלפון הנייד של הלקוח. הסיסמא תהיה בת 8 תווים לפחות, בהם אותיות באנגלית בלבד הסיסמא תכיל לפחות 2 ספרות ולפחות 2 אותיות גדולות ותו אחד שאינו אלפאנומרי )!@#$%...( הסיסמה לא תהיה זהה לשם משתמש התיישנות הסיסמא - יש לבצע חידוש סיסמא פעם בחצי שנה או על פי רצון המשתמש אך לא יותר מפעם ב- 7 ימים לכל הפחות. בניסיון לחידוש סיסמא תדיר יותר תוצג למשתמש הודעה מתאימה. 2.19.9.8.1 2.19.9.8.2 חידוש הסיסמא יבוצע באמצעות הזדהות מחודשת ב- sessin חדש. איפוס סיסמא יבוצע באמצעות פרטים מזהים נוספים: שם משתמש, מספר חוזה ולבחירה כתובת דוא"ל או מספר טלפון נייד אשר יופיעו על עמוד האיפוס בצורה המתוארת להלן:
עמוד: 12 מסך: 28 דפים 2.19.9.8.2.1 2.19.9.8.2.2 במקרה של כתובת דוא"ל תוצג כתובת הלקוח באופן חלקי על פי התבנית: us****@gm****.cm )מספר ה"*" אינו תואם את האורך של מחרוזת אמתית( במקרה של מספר טלפון נייד יוצג מספר חלקי על פי התבנית: 123****-*05. 2.19.9.8.2.8.1 2.19.9.8.2.8.2 2.19.9.8.2.3 2.19.9.8.2.4 2.19.9.8.2.5 2.19.9.8.2.6 2.19.9.8.2.7 2.19.9.8.2.8 על הלקוח להזין את הנתון במלואו. לאחר בדיקה מוצלחת של הנתון ישלח קוד חד פעמי )OTP( בתוקף של שעתיים לכתובת הדוא"ל או לטלפון נייד באמצעות הודעת SMS ע"פ בחירת הלקוח. על לקוח להזין את קוד ה- OTP בעמוד הבא ולאחר בדיקה מוצלחת יועבר הלקוח אל עמוד איפוס סיסמא לחשבונו. הסיסמא המחודשת לא תהיה זהה לשלוש סיסמאות קודמות. הסיסמא לא תשמר במערכות אלה תוצפן וכך גם לא תהיה כל אפשרות לשחזר סיסמא, אלא הפעלת תהליך חידוש על ידי הלקוח. יש להפעיל מנגנוני הגנה בפני סריקה/ניחוש סיסמא באופן אוטומטי או ידני על ידי: שימוש במנגנון CAPTCHA לאחר 2 ניסיונות הזדהות כושלים. על מנגנון CAPTCHA להיות מורכב דיו על מנת למנוע אפשרות זיהוי על ידי תוכנות אוטומטיות.)OCR( 2.19.9.8.2.8.3 2.19.9.8.2.8.4 יש להפעיל מנגנון השהיה של 30 שניות בין ניסיונות הזדהות כושלים לאחר ניסיון החמישי. בתום 10 ניסיונות כושלים יש לסגור ה- sessin ולנעול חשבון משתמש קיים בבסיס הנתונים למשך 30 דקות. בתבנית הזדהות יש להציג הודעה למשתמש: "זוהה ניסיון התקפה מכתובת אינטרנט 123.123.123.133. האירוע נרשם במערכות אבטחה של חח"י לצורך בירור". 2.19.10 תשלומים באתר באמצעות כרטיסי אשראי )סעיף מהותי( הערוצים הדיגיטליים של החברה מספקים שירות תשלומים מקוונים באמצעות כרטיסי אשראי. אי לכך חייבים לעמוד בסטנדרט PCI DSS וזאת על מנת למנוע חשיפה של ערוצים אלה לפגיעות זדוניות, תביעות נזיקין מצד חברות האשראי ו/או מצד לקוחות נפגעים.
עמוד: 13 מסך: 28 דפים 2.19.10.1 2.19.10.2 2.19.10.3 2.19.10.4 2.19.10.5 אין לשמור בשום מקום את נתוני כרטיסי האשראי של המשתמשים. יש להעביר את הפרטים לחברת הסליקה ולא להשאיר עקבות נתונים בשרת. יש להפעיל מנגנון CAPTCHA בטפסי ביצוע התשלום על מנת למנוע מתקפות רובוטים על מערכת הסליקה. יש להפעיל בדיקה האם הסכום הנגבה נמצא בטווח הגיוני לפעולת התשלום. אין לשמור פרטי כרטיס אשראי בקבצי לוג.
עמוד: 14 מסך: 28 דפים 2.19.11 הגנה לפי מודל ) I ) STRIDE המציע הזוכה יפעל ע"פ המודל שלהלן בהגנה מפני האיומים המפורטים בטבלה. מודל STRIDE פותח על ידי מייקרוסופט לצורך הצגה של איומי סייבר. להלן קישור להסבר על המודל באתר מייקרוסופט: https://msdn.micrsft.cm/en-us/library/ee823878%28v=cs.20%29.aspx?f=255&mspperrr=-2147217396 איום מנע אמצעי השתמש בהזדהות חזקה. אל תשמור סודות )לדוגמא סיסמא( בטקסט גלוי. אל תעביר credentials בטקסט גלוי על גבי הרשת. הגן על authenticatin ckies ע"י שימוש ב Secure.) Sckets Layer (SSL השתמש בהשינג של אינפורמציה data hashing ובחתימות. השתמש בחתימות דיגיטאליות. השתמש בהרשאות חזקות. authrizatin( ) strng. השתמש בפרוטוקולים עמידים למניפולציות לאורך תווך התקשורת. אבטח את תווך התקשורת ע"י שימוש בפרוטוקולים המספקים אמינות מסרים. צור מעקב רישום מאובטח. השתמש בחתימות דיגיטאליות. השתמש בהרשאות חזקות. השתמש בהצפנה חזקה. השתמש בתווך תקשורת המשלב פרוטוקולים המספקים סודיות מסרים. אל תשמור סודות )לדוגמא, סיסמאות ) בטקסט גלוי. השתמש בטכניקות הגבלת משאבים ורוחב פס. בצע אימות וסינון קלט. השתמש במנגנון CAPTCHA עקוב אחר העיקרון של הקצאת הרשאות מינימאלי והשתמש בחשבונות שרות בעלי הרשאות מינימאליות בכדי להריץ תהליכים ולגשת אל משאבים. Spfing Tampering Repudiatin Infrmatin Disclsure Denial f Service Elevatin f Privilege
עמוד: 15 מסך: 28 דפים.2.21 נפחים, עומסים וביצועים ( S ) זמני התגובה בסימולציה של מצב שיגרה או שעת שיא סבירה, בסביבה "נקייה", תואמת לדרישות במפרט זה, ללא יישומים של החברה, לא יעלה על שנייה אחת בלבד, לא כולל זמן ה-.Rund-Trip ניצול זמן מעבד ומשאבים אחרים, לא יעלה על 50%. במצבי משבר/חירום, בהם מקובלים זמני תגובה איטיים משמעותית וניצול מעבד עד 90%, המערכת תתפקד ללא קריסה ובזמן תגובה שאינו עולה על 10 שניות )לא כולל זמן Rund- )Trip ותתמוך בעומסים הבאים: גולשים אנונימיים גולשים מזוהים התנהגות גולשים לפי מצב בשעה בו-זמנית בשעה בו-זמנית 200 2000 100 1000 שיגרה 500 5000 200 שעת שיא סבירה 2000 30,000 מצב משבר/חירום חצי מיליון הצהרת המציע במענה לתת סעיף 2.21 במכרז, המציע: א. יצהיר על יכולת עמידה בדרישות תת-סעיף זה. ב. ייתן דוגמא לפיתוח אתר אינטרנט שביצע עם דרישות דומות, בטווח של עד 10% סטייה מהנתונים המפורטים בטבלה הנ"ל. בנוסף, המציע יפרט אנשי הקשר אצל הלקוח )שאצלו פיתח את האתר כאמור בדוגמא הנדרשת לעיל( ואופן יצירת קשר עימו. חברת החשמל תהיה רשאית לפנות אל איש הקשר כדי לקבל פירוט.
עמוד: 16 מסך: 28 דפים טכנולוגיה ) I ( אתר האינטרנט של החברה פותח בתשתית.Micrsft Office Sharepint Services 2010 דרישות מפרט זה מתייחסות גם לגרסא העדכנית יותר: Micrsft Office Sharepint.Services 2013 לפיכך, לכל הדרישות, המפורטות בפרק ( 4 (, נדרשת הוכחת ידע וניסיון בשתי הגרסאות. אפליקצית הסמארטפון של חברת חשמל פותחה NATIVE עבור פלטפורמות אנדרואיד ו- IOS. חברת החשמל נערכת לשדרוג טכנולוגי עתידי ולפיכך נדרש מהמציע ידע וניסיון בתוכנות קוד פתוח כגון: דרופל או ג'ומלה וגם.WrdPress 3.1 רכיבי חומרה החומרה קיימת ומסופקת על-ידי החברה. קיימות 4 סביבות: פיתוח, בדיקות,,STAGING-DMZ ייצור DMZ.3 רכיבי תוכנה בכל הסביבות מותקנים הרכיבים הבאים: אתר האינטרנט End: Frnt ניהול תוכן End: Back IIS 7 Debugging ניהול תצורה: TFS בסיס נתונים: Micrsft SQL Server 2008 R2 מערכת הפעלה אתר אינטרנט ואתר מותאם: Windws Server 2008 R2 אפליקציות סמארטפון: אנדרואיד ו- IOS דפדפנים ( S ) המציע נדרש להתאים את הפיתוח לדפדפנים הבאים: Internet Explrer גרסה 9 ומעלה Edge Ggle Chrme Firefx Safari Opera הצהרת המציע א. המציע יצהיר על יכולתו להתאים את הפיתוח ולתמוך בכל הדפדפנים שהוזכרו לעיל ויפרט כיצד הוא יבצע התאמה. 3.2 3.3 3.4
עמוד: 17 מסך: 28 דפים ב. ג. המציע יצהיר כי כל שינוי או פיתוח במערכת ניהול התוכן יותאם לדפדפן Internet Explrer גרסה 11 ומעלה או כל גרסה או דפדפן שיהיו תקניים בחברת החשמל. מעת לעת מתבצע מהלך של שדרוג דפדפנים או רכיבים שלהם. המציע יצהיר שהוא מודע לכך שסוגי הדפדפנים המוזכרים בסעיף זה לגלישה באינטרנט יכולים להשתנות לגרסאות מתקדמות או אחרות. המציע יתחייב לתמוך בגרסאות המפורטות בסעיף זה וכן בגרסאות משודרגות או מתקדמות יותר. נגישות ( S ) הספק יפתח בהתאם להנחיות הנגישות, המתפרסמות בתקן W3C ובתקן הישראלי לנגישות. נדרש ניסיון בהנגשת אתרים. המציע יפרט 2 דוגמאות של אתרים מונגשים שהקים או הנגיש. המציע יפרט נסיון בהנגשה בעזרת מוצרי הנגשה ובפרט נסיון עם יוזרפירסט. הצהרת המציע בנוסף, במסגרת המענה לתת-סעיף זה, המציע יצהיר כי הוא מודע לכך שחברת החשמל מחויבת, על-פי חוק, לעמוד בתקני הנגישות, ולפיכך המציע מתחייב לכך שאם יזכה במכרז, הוא יפתח את הערוצים הדיגיטליים של החברה על-פי תקן הנגישות, רמה AA ובעזרת כל מוצר הנגשה אשר נבחר /יבחר על ידי החברה ובתיאום עם החברה. בנוסף, המציע יצהיר על כך, כי הוא מתחייב להתעדכן כל העת בתקן הנגישות ולשמור על רמת הנגשה AA למשך כל תקופת ההתקשרות. 3.5
עמוד: 18 מסך: 28 דפים 4. מימוש המציע רשאי להגיש הצעה אחת בלבד. כל הצעה תהווה מכלול המענה לדרישות במפרט, כולל פתרונות צד שלישי. במענה לדרישות, על המציע להתייחס גם לסעיפי המפ"ל )המפ"ל מצורף כנספח לפרק המנהלי במכרז(. השמטה של מידע או חוסר מענה לסעיף כלשהו במפרט )שסומן כסעיף שמחייב תשובה/פירוט וכד'( יחשב כהעדר יכולת ויקבל ציון אפס. במקומות בהם אין למציע יכולת עצמאית והוא מערב יכולות צד שלישי יש לציין זאת מפורשות, ולפרט זאת בסעיף קבלני משנה - סעיף.)4.3.6( 4.1 גורמים מעורבים בחברת החשמל ( I ) הגורם המעורב ועדת היגוי מינהלת הפרויקט צוות הפרויקט מינהלת האתר תפקיד יו"ר הועדה ופורום הנהלת האגף יו"ר המינהלת וצוות הנהלה מצומצם מנהל הפרויקט וצוות פיתוח ותשתיות, כולל נציגי מרכזי המחשבים, אבטחת מידע ואינטגרציה יו"ר המינהלת וועדת ניהול התוכן 4.2 תאור כללי של המציע ( M ) על המציע להיות חברה ישראלית או חברה בעלת נציגות ישראלית )עם לפחות 10 עובדים דוברי עברית המועסקים בנציגות בישראל(, כך ששירות התמיכה, התחזוקה, הפיתוח ובנק השעות הנדרשים במסמכי מכרז זה יתבצעו בארץ ובעברית. במענה לסעיף זה, המציע יצרף מסמך המעיד על היותו חברה ישראלית או חברה בעלת נציגות ישראלית. 4.3 הרכב הצוות מטעם המציע ( S ) 4.3.1 צוות המציע ( M ) 4.3.2 צוות המציע יכלול: מנהל פיתוח מומחה, צוות פיתוח, מעצב/ים גרפיים, מדריך/ים. קריטריונים שיבחנו: ( S ) קורות חיים, המלצות, דוגמאות, ראיון אישי. בחינת הקריטריונים תחול על: מנהל הפיתוח, מעצב, מדריך, החברה המציעה )המלצות בלבד(.
עמוד: 19 מסך: 28 דפים על המציע לצרף להצעתו, כמפורט להלן ולפי דרישות סעיף ( 4.3.5 (: קורות חיים המלצות דוגמאות לפיתוח ע"י מנהל הפיתוח בהצעה מנהל הפיתוח, מעצב, מדריך שני ממליצים עבור כל אחד מהגורמים: החברה המציעה, מנהל הפיתוח, מעצב, מדריך. יש לכלול בהצעה פרטי הממליצים כדלקמן: שם פרטי, שם משפחה, תפקיד, מספר טלפון משרד, מספר טלפון נייד, כתובת דוא"ל. יש לפרט עבור כל גורם: ניסיון רלבנטי בשנים דוגמאות של אתרים חיצוניים פעילים, מבוססי טכנולוגיה המתוארת בסעיף )3(, בעלי אופי שירותי, עסקי ותדמיתי, המייצגים חברות ישראליות, מסדר גודל נדרש*. על הדוגמאות לכלול יכולות כמפורט בסעיף.)4.3.5( על הדוגמאות להיות מהשנתיים האחרונות. 1 דוגמא לפיתוח שנעשה ב-.SP 2010 1 דוגמא לפיתוח שנעשה ב-.SP 2013 1 דוגמא לאתר מותאם אחת מתוך שתי הדוגמאות לעיל, אשר הותאמה לסמארטפון. 1 דוגמא לאפליקצית אנדרואיד שפותחה.NATIVE 1 דוגמא לאפליקצית IOS שפותחה.NATIVE 2 דוגמאות לאתרים שפותחו בקוד פתוח דרופל, ג'ומלה,.WrdPress יש לתת דוגמאות מ- 2 )מתוך 3( סביבות פיתוח שונות שהוזכרו לעיל. על הדוגמאות להיות מהשנתיים האחרונות. 1 דוגמא לעיצוב אתר אינטרנט. 1 דוגמא לעיצוב אפליקצית סמארטפון. דוגמאות לעיצוב ע"י המעצב בהצעה ראיון אישי במהלך המכרז, מנהל הפיתוח, מעצב ומדריך יזומנו לראיון אישי במשרדי החברה. 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 * סדר גודל נדרש: עבור אתר אינטרנט: כחצי מיליון לקוחות פרטיים וכ- 10,000 לקוחות עסקיים עבור אפליקצית סמארטפון: כ- 250,000 לקוחות פרטיים וכ- 1,000 לקוחות עסקיים
עמוד: 20 מסך: 28 דפים 4.3.3 נדרש צוות קבוע ( I ) אם יוחלף גורם כלשהו מהצוות או הצוות כולו במהלך תק' ההתקשרות, באחריות המציע לאפשר לצוות הפרויקט בחברה לראיין את הגורם החדש/הצוות החדש ולוודא עמידתו בקריטריונים שנדרשו במכרז. חח"י תהא רשאית במהלך המכרז, עפ"י שיקול דעתה הבלעדי, לאפשר למציע להחליף עובד בצוות הפרויקט שלא יימצא מתאים )לרבות הצוות כולו(, בעובד אחר, תוך 5 ימים או תוך פרק זמן אחר, כפי שתקבע חח"י, שירואיין וינוקד לפי חלקו בהצעה, בהתאם להוראות המפ"ל. למקרה שמדובר על החלפה במהלך ביצוע הפרוייקט, כאמור בפסקה הבאה, העובד החדש המוצע יצטרך לעבור תהליך בדיקת התאמה/ בחינה ואישוריאושר ע"י חח"י לפני כניסתו לפרויקט. האמור לעיל יהיה בתוקף גם במהלך ביצוע הפרויקט, כלומר, אם יוחלף גורם כלשהו מהצוות )או הצוות כולו( ולא יעמוד בקריטריונים שנדרשו במכרז, המציע יעמיד גורם/צוות חלופי אחר לאלתר עד מציאת צוות מתאים, לפי קביעת צוות הפרויקט בחברה. למען הסר ספק, עיכובים בנושא זה ו/או אי המצאת בעל תפקיד/גורם/צוות חלופי המתאים, לפי דרישות החברה )לכל הפחות לפי הוראות מכרז זה( ובלו"ז סביר, המותאם ללו"ז הפרויקט, יהוו הפרת יסודית של החוזה מצד הספק הזוכה, לרבות הסעדים הנתונים לחברה בגין ההפרה על פי ההסכם והדין. ראו התייחסות גם בסעיף 0.8.14 בפרק המנהלה " זמינות משמשי המציע ו/או קבלני המשנה מטעמו". ) I 4.3.4 מנהל הפיתוח מטעם המציע ( המציע הזוכה יעמיד מנהל פיתוח מומחה מטעמו, אשר ילווה את הפרויקט, החל מיום חתימת חוזה בעקבות זכיית המציע במכרז ועד תום תקופת ההתקשרות. כאמור בסעיף 4.3.2 לעיל, המציע יפרט בהצעתו מיהו מנהל הפיתוח המוצע מטעמו, יצרף קו"ח שלו ואת יתר הפרטים הנדרשים בסעיף 4.3.2. להלן נושאים שיהיו באחריות מנהל הפיתוח של המציע הזוכה: להביא את כל הערוצים הדיגיטאליים של החברה ( האתרים/מערכות/אפליקציות וכד'( לסיום מוצלח בהיבט תכולה, איכות התוצרים ועמידה בלו"ז הנדרש. לצוות לפרויקט אנשי מקצוע רלבנטיים. לדווח למנהל הפרויקט בחברה על מצב התקדמות הפיתוח, ניהול שינויים וסיכונים, ולהציג אב טיפוס. להיות אחראי על ביצוע בדיקות פונקציונליות, איכות ומסירה טרום ההתקנה בחח"י. להיות אחראי על ביצוע ההתקנות בחח"י, כולל בדיקות פונקציונליות עד תקינות המוצר ושלמותו. להיות אחראי על עמידה בדרישות אבטחת מידע, כפי שהוגדרו במפרט זה וכפי שיוגדרו ע"י החברה לאורך כל תקופת ההתקשרות.
עמוד: 21 מסך: 28 דפים ידע וניסיון של המציע ( S ) על המציע להיות בעל 2 שנות ידע וניסיון לפחות באיפיון ובפיתוח: אתרי אינטרנט, אתרים מותאמים למובייל, אפליקציות סמארטפון, וכמו כן עיצוב גרפי ובתחזוקת אתרי אינטרנט שירותיים, עסקיים ותדמיתיים, עבור חברות בסדר הגודל שהוגדר בסעיף 4.3.2. 4.3.5 המציע יפרט יכולות, רמת ידע וניסיון בתחומים להלן ויצרף להצעתו 2 המלצות של לקוחות עבורם בוצעו פרויקטים הכוללים את המפורט בתתי הסעיפים הבאים: 4.3.5.1 פיתוח אתרי אינטרנט בתשתית,SharePint 2010 נדרש גם ידע וניסיון בגרסת SharePint 2013 ורכיבי התשתית שהוגדרו בפרק טכנולוגיה ( סעיף ) 3 פיתוח אתרים מותאמים למובייל תוך שימוש ב- HTML5, CSS, Java Script 4.3.5.2 ומנוע רספונסיבי לפחות שנתיים ידע וניסיון בפיתוח אפליקציות NATIVE בפלטפורמות אנדרואיד 4.3.5.3 ו- IOS. כתיבת WSDL, Jsn/Rest Api שירות עצמי, תהליכי תשלום וסליקה 4.3.5.4 מערך הזדהות וניהול הרשאות מול Active Directry 4.3.5.5 4.3.5.6 ניסיון בכתיבת XML וצריכת WEB SERVICES ממערכת.SAP-ERP המערכות תתממשקנה עם מערכות ליבה בעזרת שכבת API'S מבוססי,WEB SERVICES המשתמשים ב- DATA POWER כתווך קישוריות. שכבת ה- API'S תפותח בחברה ותועמד לרשות המציע במהלך הפרויקט יכולת התממשקות ל- API של מוצר רב-ערוציות WIZSUPPORT ומוצרי כספת 4.3.5.7 הכולל WEB CONTENT MANAGEMENT מוצר והטמעת בפיתוח וניסיון ידע 4.3.5.8 WORDPRESS WORKFLOW 4.3.5.9 מנגנון העלאת קבצים בצורה מאובטחת 4.3.5.10 אתרים רב-לשוניים 4.3.5.11 פיתוח אתרים מבוססי קוד פתוח: דרופל, ג'ומלה, 4.3.6 פרטים על קבלני המשנה ( S ) המציע ימלא את הטבלה הבאה רק במידה והוא משלב בהצעתו קבלני משנה. המציע יתייחס לשילוב קבלני משנה, ויציין אילו סעיפים מיועדים להתבצע על ידו כקבלן ראשי ואילו ע"י קבלני המשנה מטעמו, וכמוכן המציע יפרט: דרישה פירוט שם קבלן המשנה תחום האחריות במכרז זה )תיחום האחריות בין הקבלן הראשי לבין קבלני המשנה, אם יש, ובין קבלני המשנה לבין
עמוד: 22 מסך: 28 דפים עצמם( שם רשמי של קבלן המשנה ומספר ח.פ. )יש לצרף אישור על אמיתות הנתונים( כתובת, מס' טלפון, מס' פקס', כתובת דוא"ל של קבלן המשנה שמות בעלי החברה )כלומר- של קבלן המשנה( שם נציג )מטעם קבלן המשנה( לצורך מכרז זה + תפקיד הנציג )בעלים / מנהל הפרויקט / מכירות וכו'( תקן ISO27001 / ISO 9001:2008 )קיים / לא קיים אצל קבלן המשנה. אם קיים- יש לצרף אסמכתאות/אישורים רשמיים( 4.4 תכנית עבודה ( I ) תכנית העבודה של הפרויקט כולו תכתב ע"י מנהל הפרויקט בחברה. 4.4.1 שיטת הפיתוח ( S ) הפיתוח יתבצע ע"י המציע, על-פי תכולה שתוגדר ע"י מנהל הפרויקט בחברה ועל-פי דרישות מסמכי האפיון שימסרו למציע, ויהיה באחריות המציע. החברה שומרת לעצמה זכות לפתח רכיבים באתר האינטרנט ובאפליקציה בתיאום, בליווי ובתמיכה של המציע. האיפיון יתבצע ע"י החברה או ע"י המציע וזאת בהתאם לצורך, שיוגדר ע"י מנהל הפרויקט בחברה. נדרש אישור מנהל הפרויקט בחברה, למסמך האיפיון וזאת לפני תחילת פיתוח קוד. כל שינוי באיפיון דורש אישור מנהל הפרויקט בחברה. העיצוב הגרפי יתבצע לפי ספר הגדרות העיצוב, שימסר למציע ע"י החברה. נדרש נסיון של שנתיים לפחות של המציע בפיתוח, על-פי שיטת הפיתוח המוגדרת בסעיף זה. כל פיתוח אשר יתבצע ע"י המציע, יותאם לדרישות שיטות פיתוח של החברה, המתוארות להלן: 4.4.1.1 הפיתוח יתבצע על פי מודל השכבות והפרדה מוחלטת ביניהן: שכבת ממשק המשתמש שכבת הלוגיקה העסקית שכבת ממשקים (FACADE( שכבת הנתונים )מאגרי מידע ומערכות.)BO הפיתוח יעשה במהדורות, על-פי תכולה מוגדרת מראש.
עמוד: 23 מסך: 28 דפים הפיתוח יתבצע עפ"י עקרונות של יכולת שחזור קוד. הפיתוח יהיה גנרי וייעשה שימוש חוזר ברכיבי קוד. כל חבילת קוד, שתפותח במשרדי המציע, תהא תואמת לכלים ולסביבות העבודה בחברה ותותקן בתשתית TFS בחברת החשמל. 4.4.1.2 4.4.1.3 4.4.1.4 תשובת המציע במענה לסעיף זה: המציע יפרט ניסיון בעבודה לפי שיטת הפיתוח הנדרשת, לרבות פירוט התקופה בה נרכש הניסיון. 4.5 תפעול שוטף ( S ) החברה תפעיל את הערוצים הדיגיטליים בעצמה. 4.5.1 שליטה ובקרה )שו"ב( ( S ) המציע נדרש להתאים תפעול הערוצים הדיגיטליים לכלי שליטה ובקרה הקיימים בחברה SCOM( )HP OPENVIEW / MOM/, או לכל מערכת שו"ב שתידרש ע"י החברה. תשובת המציע במענה לסעיף זה המציע יפרט רמת ידע וניסיון בכלים אלו וביכולתו להתאים את תפעול הערוצים הדיגיטליים לכל כלי שליטה ובקרה שיידרש. 4.5.2 יכולות גיבוי ושחזור ( M ) )I( גיבוי ושחזור מובנה של הערוצים הדיגיטליים לכל תוצרי הקונפיגורציה, אינטגרציה, קוד, תוכן וכל מרכיב אחר במצב מלא של המערכת ייעשה בתשתית ובאחריות חברת החשמל. ) M (במענה לסעיף זה, המציע יצהיר על הסכמתו והתחייבותו למלא אחר דרישות חברת החשמל להתאמת הפיתוח לתשתית הנדרשת בחברה לקיום יכולות גיבוי ושחזור כנדרש בסעיף זה. ) 4.6 תיעוד ( S 4.6.1 4.6.2 תיעוד שהחברה תעביר למציע ( I ) לאחר זכייתו, יקבל המציע מהחברה תיעוד קיים להמשך פיתוח הערוצים הדיגיטליים לפי החלוקה הבאה: תיעוד תפעולי קיים. תיעוד תהליך הפיתוח חח"י תעביר מסמכי איפיון לצרכי פיתוח. תיעוד שהמציע יעביר לחברה ( I )
עמוד: 24 מסך: 28 דפים לאחר זכייתו, יעביר המציע לחברת החשמל: כל שינוי באיפיון וימסור תיעוד מלא ועדכני של המערכת. נהלים להפעלת המערכת בחברה, להשגת המטרות הרשומות במפרט זה ולמשך תקופת החוזה בשפה העברית. לדוגמא: נהלי התקנה, אבטחת מידע, גיבוי ושחזור, תחזוקה, מיגרציה,.TROUBLE SHOOTING נהלי ההתקנה יקחו בחשבון שימוש בכלים סטנדרטיים בחברה, ויתייחסו לפרמטרים של מערכת ההפעלה, גרסאות מערכת הפעלה, תוכנות נלוות נדרשות, פלטפורמות, דרישות משאבי חומרה ותוכנה, סוגי שרתים וגרסאותיהם. תשובת המציע המציע במענה לסעיף זה )S( ימסור דוגמא לתיעוד מסמכי איפיון וניהול גרסאות שוטף. שירות ( S ) 4.7 ותחזוקה גרסאות ורישיונות נדרש להתאים את הפיתוח לכל עדכון עדכון גרסאות ורישיונות באחריות חח"י. המציע גרסה או רכש רישיונות חדשים, לאורך כל תקופת התקשרות הבסיס והאופציה. שירות תמיכה בפיתוח המציע מתחייב לספק לחברה תמיכה נדרשת למיגרציה לגרסאות החדשות. שירות 3 אנשי תמיכה לפחות. התמיכה של המציע חייב לכלול המציע מתחייב למתן שירות לחברה, עפ"י המאפיינים הבאים: זמינות המציע - זמן תגובה תוך 3 שעות מזמן פתיחת הקריאה פרק הזמן לפתרון תקלות במקרה של תקלה במערכת חירום בשעת חירום, כפי שתוגדר ע"י החברה, זמן תגובה מיידי ופתרון מיידי. בכל מקרה אחר, תוך 3 שעות מזמן הקריאה ויישום פתרון בפרק זמן שלא יעלה על 3 שעות. התמיכה תינתןהן טלפונית והן ע"י הגעה של איש/אנשי תמיכה למשרדי החברה על-פי הצורך שיוגדר ע"י החברה. שעות, עליו לפנות לקבלת במידה והמציע אינו מסוגל לפתור תקלה תוך 3 סיוע ממומחה, על חשבון המציע. במקרה זה, זמן התיקוןלא יעלה על 10 שעותאו פרק זמן אחר על-פי רמת הקריטיות של הרכיב התקול, ובהתאם להחלטת החברה.)אשר יוכל להיות קצר מ- 10 שעות(. 4.7.1 4.7.2 תשובת המציע במענה לסעיף זה )S( א. ב. ג. המציע יתחייב כי יתאים את הפיתוח לכל עדכון גרסה או רכש רשיונות חדשים במשך כל תקופת ההתקשרות. המציע יתחייב כי יספק לחברה שירות תמיכה ותחזוקה כנדרש בסעיף זה וכי יעמיד לרשות החברה 3 אנשי תמיכה לפחות. המציע יתחייב לעמוד בזמינות הנדרשת.
עמוד: 25 מסך: 28 דפים 4.8 השתלבות בארגון הנעת המערכת ( S ) על המציע לספק את הפעילויות הבאות: הדרכות, תמיכה, ליווי והטמעה, העברת ידע. ) I ( 4.8.1 הדרכות SHAREPOINT ההדרכות תתקיימנה באתר/י חברת החשמל בתשתית ובסביבת הפיתוח של החברה. קהל היעד להדרכה: צוות הפיתוח, 20 ימי הדרכה * עד 12 מפתחים שיהיו קהל היעד להדרכה. שכפול החומר למודרכים יהיה באחריות המציע. על המציע לצרף דוגמת סילבוס להדרכות בשפה העברית. תמיכה, ליווי והטמעה על המציע לספק שירותי תמיכה, ליווי והטמעה לצוות הפרויקט בחברה. השירות יינתןהן לצורך פיתוח יישומים בתשתית המוצעת והן לצורך העברת הידע למערכות, שיפותחו ע"י המציע. העברת הידע המציע יבצע העברת ידע של הקוד שלמד עם זכייתו במכרז, ולכל המערכות שיפתח עבור החברה, ויספק לחברה את הרכיבים הבאים: תכנית לימוד של המציע לקוד הקיים תיעוד כל המערכות שיפותחו בשפה העברית תמיכה והטמעה לצוות הפיתוח תכנית העברת ידע לצוות החברה ושילובו בפיתוח 4.8.2 4.8.3 תשובת המציע במענה לסעיף זה המציע יפרט את תכנית ההדרכות, התמיכה, הליווי, ההטמעה והעברת הידע ויצרף דוגמת סילבוס בעברית.
עמוד: 26 מסך: 28 דפים 4.9 חוסן ואמינות ( S ) תכנית בדיקת ביצועים ועומסים הכנת תרחישים ותסריטים לבדיקות ביצועים ועומסים תהא באחריות המציע. הבדיקות תתקיימנה בחברה ואצל ספק האינטרנט של החברה ובסביבה המדמה סביבת ייצור. לאחר זכייתו, המציע יהיה מעורב בתהליכי בדיקות המערכת ואבטחת איכותה עם גורמים בחברה ויהיה מחויב לשיפור וייעול היישום בהתאם לממצאי בדיקות הביצועים והעומסים. נדרש ניסיון שנתיים ומעלה בהכנת הנדרש בסעיף זה. תכנית בדיקות מסירה הכנת תרחישי בדיקות מסירה תתבצע באחריות המציע, ותסתמך על מסמכי האפיון, כפי שקבל ממנהל הפרויקט בחברה. הבדיקות תתבצענה ע"י המציע ותימסרנה לחברה בליווי מסמך הבדיקות, הכולל את שם ותיאור הרכיב הנבדק, תוצאה במצב תקין, תוצאה לאחר בדיקה. הבדיקות תאושרנה ע"י החברה לאחר ביצוע בדיקות קבלה על ידה. נדרש ניסיון שנתיים ומעלה בהכנת הנדרש בסעיף זה. כלי בדיקות נדרש ניסיון שנתיים ומעלה בהפעלת להתאים עצמו לכלים הנהוגים בחברה: כלי בדיקה אחרים, עפ"י שיקול דעתה של החברה. כלי בדיקות לביצועים ועומסים. המציע מתחייב LOAD RUNNER של חברת HP MERCURY או כל 4.9.1 4.9.2 4.9.3 תשובת המציע במענה לסעיף זה א. המציע יפרט ניסיון בכתיבת תרחישים ותסריטי בדיקות ביצועים ועומסים, ויצהיר כי ויתחייב לשפר ולייעל את היישום בהתאם לממצאי המבדקים. ב. המציע יפרט ניסיון בכתיבת תרחישי בדיקות מסירה ויתחייב כי מתחייב לבצען, טרם מסירת חבילת קוד לחברה והעברתו בליווי מסמך בדיקות. ג. המציע יפרט ניסיון בהפעלת כלי בדיקות ביצועים ועומסים. ויתחייב להתאים עצמו לכלים הנהוגים בחברה.
עמוד: 27 מסך: 28 דפים נספחים: נספח 1: דרישות אבטחת מידע ( I ) סכנות ואיומים נפוצים על יישומי אינטרנט השתלטות על המערכת לצורך חדירה פנימה לתוך הארגון. הפעלת יישומים במרמה, ריגול אחר משתמשים, גניבת מידע, גניבת זהות. הונאה - השחתת התצוגה, מחיקת תוכן. הצגת מידע שגוי, זיוף נתונים )ובכך פגיעה במשתמשים ובמהימנות של המערכת(. מניעת שירות )DS( במטרה של האטת המערכת או השבתתה. דיוג )Phishing( - ניסיון לגניבת מידע רגיש על ידי התחזות ברשת האינטרנט. שיטות פעולה של תוקפים: איסוף מידע חשיפת פרטים על המערכת: מעה"פ, סביבות עבודה, גרסאות, זיהוי תהליכים, שמות משתמשים, סיסמאות, פורטים פתוחים, שירותים פעילים וכו'. וידניים, הפקת הודעות מערכת או הודעות מתבצע באמצעות כלי סריקה אוטומטיים, שגיאה כתוצאה משימוש שגוי באופן מכוון על מנת לחשוף מידע פנימי. זיהוי מנגנוני ניהול תצורה ותוכן של המערכת ותקיפתם. זיהוי רכיבים מגרסאות ישנות לצורך ניצול פרצות האבטחה ידועות. ניצול מנגנוני הזדהות חלשים, ניצול מנגנון ניהול משתמשים לא מאובטח. הרצת קוד זדוני. הסנפת תעבורה לא מוצפנת. ניצול כשלים בצד הלקוח להזרקת קוד ושיבוש המידע שמועבר למערכת בשיטות: ניצול הרשאות לקויות Crss-site scripting HTML, XML, LDAP, SQL injectin ניהול המערכת 3.1 לא יתאפשר ניהול ועדכון המערכת דרך רשת האינטרנט. 3.2 ניהול המשתמשים יתבצע דרך ממשק ייעודי אשר אינו חשוף לאינטרנט. 3.3 ניהול המשתמשים יתבצע על בסיס Active Directry פנימי ייעודי אשר יועתק בתהליך רפליקציה ל- Read-Only Active directry ב- DMZ. 3.4 יוצפנו נתונים חסויים בקבצי תצורה. 3.5 התקנת האפליקציה תתבצע על כונן נפרד ממערכת ההפעלה. 3.6 האפליקציה לא תבצע כתיבה למחיצות מערכת ההפעלה של השרת. 3.7 הקשחת שרת WEB 3.7.1 לא תאושר התקנה של כלי פיתוח כלשהם על שרתי ייצור. 3.7.2 תתאפשר התקנה של תוכנות הכרחיות לצורך פעילות השרת והאפליקציה. 3.7.3 יופעל תיעוד מלא בשרתי.WEB 3.7.4 חל איסור על שימוש במתודות שאינן.HEAD, POST, GET.1.2.3
עמוד: 28 מסך: 28 דפים 3.7.5 איסור על נווט ע"י שימוש בתבנית "../..". 3.7.6 השרת יענה לדפים בעלי סיומת מורשות בלבד, דוגמת aspx(.)html, asp, המציע יעביר רשימת הסיומות בצירוף תיאור המנוע הדרוש לטיפול בסוג רלוונטי מערכת ניהול תוכן 4.1 ממשק ניהול יש להפרידו לגמרי מחלק האתר המוצג לגולשים. 4.2 המערכת תורכב ממערכת איזון עומסים Balancer( )Lad אשר בנוסף מבצעת SSL )Frntend( שרתים קדמיים,)Web Applicatin Firewall( מערכת הגנת יישום,Offlad ואחוריים )Backend( כאשר: 4.2.1 שרת קדמי מקבל בקשות ממבקרי האתר מהאינטרנט, אשר עברו את מערכת ה- Firewall האפליקטיבי )WAF( ומערכת ניהול עומסים. שרת אחורי משמש למטרות ניהול כגון: 4.2.2 עדכוני תוכן 4.2.2.1 ניהול משתמשים 4.2.2.2 גיבויים 4.2.2.3 תקשורת מול בסיס נתונים וכו'. 4.2.2.4 עדכוני תוכן באמצעות ממשק HTTP או Web Service 4.2.3.4