פרופיל המערכת 1. המערכת הכספית 2. התהליכים העסקיים המטופלים במסגרת שלב א' של אב- הטיפוס: 3. התהליכים העסקיים המטופלים במסגרת שלב ב' של אב- הטיפוס: 4. תאום תהליכים בין מערכות ממס"ח (דוגמא) 5. אבטחת מידע 6. אמצעי אבטחת מידע כפתרון טכני לבעיות משפטיות 7. חתימה דיגיטלית 8. (EVIDENCE) ראיות 1. המערכת הכספית גבולות המערכת: טיפול בעסקות יבוא ויצוא, העברות מט"ח, מימונים, פיקוח הרשויות המוסמכות על תנועות מט"ח וביטוח סיכוני סחר חוץ. המערכת מטפלת בהגדרת התהליכים בתחום, אפיון המסרים המועברים בין המשתתפים בתהליכים ויישום המסרים. המשתתפים הפעילים במערכת: יצואנים, יבואנים, בנקים מסחריים, החברה לביטוח סיכוני סחר חוץ, מכס. התהליכים המטופלים במערכת: התהליכים ממומשים באמצעות מסרי EDI בסטנדרט UN/EDIFACT . תהליך היצוא: קבלת תמורות בחשבון פתוח, משלוח מסמכים לגבייה וגבייה נקיה, קבלת אשראים דוקומנטריים, קבלת ערבויות ופוליסות מבסס"ח, ביצוע מימונים. תהליך היבוא: תשלומים בחשבון פתוח, קבלת מסמכים לגבייה וגבייה נקיה, פתיחת אשראים דוקומנטריים, הסבות שטרי מטען ואישורים למוביל. סטטוס המערכת: המערכת נמצאת בשלבי הקמה ותעבור להפעלה מבצעית בתחילת שנת 7991. במקביל, מתבצעת פעילות שיווקית להרחבת המערכת ע"י צרוף משתמשים נוספים ופעילות לקישור המתג המרכזי של המערכת למתגים נוספים (כגון: למתג LI-SCC, במסגרת הפעילות לתאום ואיחוד מערכות). המערכת מוקמת בשלבים, ובמסגרתה נשכרו שירותי מתג קיים. בשלב הראשון הוגדר אב טיפוס, בהשתתפות חמישה בנקים, עשר חברות תעשייתיות (המבצעות פעילות סחר חוץ של יבוא ויצוא) והמכס. המתג המרכזי של המערכת ממוקם במס"ב. כיום מקושרים למערכת, ישירות או באמצעות תחנת קצה, חמשת הבנקים הגדולים וארבעה מתוך עשרת התעשיינים, ומתבצעים טסטים סופיים. חלק מהמסרים כבר מועברים בסטטוס של ייצור. ראש העמוד 2. התהליכים העסקיים המטופלים במסגרת שלב א' של אב- הטיפוס: א. העברות כספיות בתהליכי היבוא והיצוא: המסרים הנכללים בתהליך זה הם: הודעה על קבלת תמורה (בנק-יצואן) הוראה להפקדת תמורה (יצואן-בנק) דחיית הפקדת תמורה (בנק-יצואן) הודעת זיכוי (בנק-יצואן) הוראת תשלום בינלאומית (יבואן-בנק) דחיית הוראת תשלום בינלאומית (בנק-יבואן) הוראת תשלום מקומית (קונה-בנק) דחיית הוראת תשלום מקומית (בנק-קונה) הודעת חיוב (בנק -יבואן/קונה) הרבעה ,היסרבנוק ,הרמה ,השיכר :ח"טמב תולועפ עוציבל השקב (יבואן-בנק) דחיית בקשת ביצוע פעולות במט"ח (בנק-יבואן) ב. סטטוסים ותהליכים כלליים: המסרים הנכללים בתהליך זה הם: בקשת סטטוס (לקוח-בנק) סטטוס עסקות פתוחות (בנק-לקוח) תחזית פרעונות (בנק-לקוח) נתוני עסקה (בנק-לקוח) הסטוריה של עסקה/ארועים צפויים בעסקה (בנק-לקוח) דווח שערי מט"ח (בנק-לקוח) דווח תנועות בחשבון (בנק-לקוח) תזכורות (בנק-לקוח) ג. אישור למוביל והסבת שטר מטען בתהליך היבוא (ראה פרוט במסגרת נושא תאום תהליכים): המסרים הנכללים בתהליך זה הם: בקשת אישור למוביל/הסבת שטר מטען (יבואן-בנק) דחיית בקשת אישור למוביל/הסבת שטר מטען (בנק-יבואן) אישור למוביל/הסבת שטר מטען (בנק-מוביל) ראש העמוד 3. התהליכים העסקיים המטופלים במסגרת שלב ב' של אב- הטיפוס: ד. אשראים דוקומנטריים ומסמכים לגבייה בתהליכי היבוא: המסרים הנכללים בתהליך זה הם: בקשה לפתיחת אשראי דוקומנטרי (יבואן-בנק) בקשה לתיקון אשראי דוקומנטרי (יבואן-בנק) אישור/דחיית בקשת פתיחת האשראי (בנק-יבואן) אישור/דחיית בקשת תיקון תנאי האשראי (בנק-יבואן) הודעה על קבלת מסמכים באשראי דוקומנטרי (בנק-יבואן) הודעת הסתייגויות באשראי דוקומנטרי (בנק-יבואן) הודעת שחרור/דחיית הסתייגויות באשראי דוקומנטרי (יבואן-בנק) הודעה על קבלת מסמכים לגבייה (בנק-יבואן) הודעה על קבלת שינוי תנאי מסמכים לגבייה (בנק-יבואן) הודעה על קבלת גבייה נקייה (בנק-יבואן) ה. אשראים דוקומנטריים ומסמכים לגבייה בתהליכי היצוא: המסרים הנכללים בתהליך זה הם: הודעה על קבלת אשראי דוקומנטרי (בנק-יצואן) הודעה על קבלת תיקון לתנאי אשראי דוקומנטרי (בנק-יצואן) בקשה למשלוח מסמכים לגבייה (יצואן-בנק) בקשה לשינוי תנאי מסמכים לגבייה (יצואן-בנק) בקשה למשלוח גבייה נקייה (יצואן-בנק) ראש העמוד 4. תאום תהליכים בין מערכות ממס"ח (דוגמא) במסגרת תאום התהליכים בין המערכת הכספית למערכות מטענים אויר ומטענים ים פותח בממס"ח מסר בנושא של אישור למוביל/הסבת שטר מטען, הנשלח מבנק למוביל או למשלח (עפ"י הגורם שהנפיק את שטר המטען), באותם המקרים בהם מבקש לקוח (יבואן) לשחרר סחורה לפני הגעת שטר המטען המקורי לידיו (כאשר שטר המטען על שמו) או כאשר שטר המטען הוא על שם הבנק. המסר מתוכנן להחליף תהליך ידני המתבצע כיום, של הנפקת מכתב שיפוי ("אישור למוביל") ע"י הבנק והעברתו למוביל או למשלח וכמו כן יהווה אישור למשלח או למוביל שאכן הבנק ביצע הסבה של שטר מטען (כאשר השטר המוסב יועבר פיזית למשלח או למוביל בהמשך). המסר מתוכנן להיות מועבר באמצעות קישוריות (TCENNOCRETNI) בין המתג של מס"ב (אליו מחוברים הבנקים) למתג של LI-SCC (אליו מחוברים המובילים והמשלחים). המטרות שיושגו הן: שיפור השירות ללקוח ייעול התהליך קיצור משך זמן שחרור הסחורה (לפחות לגבי אותו חלק בתהליך השיחרור התלוי במוביל או במשלח). היישום כולל שני תהליכים, הממומשים באמצעות מסרי IDE: בקשת יבואן (או עמיל מכס בשם היבואן) מבנק להסבת שטר מטען או להנפקת כתב שיפוי ("אישור למוביל") דחיית בקשת היבואן (או עמיל המכס) ע"י הבנק או אישור הסבה או אישור שיחרור הסחורה מהבנק למוביל או למשלח ראש העמוד 5. אבטחת מידע מהות ה- IDE הינה תקשורת בין מחשבים של ארגונים שונים. כעקרון, בעבודת IDE אין בכלל (או יש מעט) התערבות אנושית. במצב כזה יש צורך בטכניקות לאבטחת אמינות, דיוק וגילוי פעולות הונאה. שיטות עיקריות לאבטחת מידע: זיהוי משתמש חתימה דיגיטלית הצפנה ישנן שתי דרכים עיקריות ל זיהוי המשתמש במערכת מחשב: ע"י אמצעי פיסי (כגון: DRAC TRAMS ). ע"י מידע אישי חסוי כמו מספר מזהה אישי (NIP) או DROWSSAP . ההצפנה מספקת חשאיות למידע והחתימה הדיגיטלית מספקת למידע אותנתיות ושלמות ותומכת באי היכולת להתכחש למידע (רק השולח יכול לחולל את החתימה). חתימה דיגיטלית: המסר לא מוצפן אלא "נחתם" באמצעות המפתח הפרטי של השולח. המקבל מאמת את החתימה באמצעות המפתח הציבורי של השולח. הצפנה סימטרית: המידע מוצפן ע"י השולח ומפוענח ע"י המקבל באמצעות אותו מפתח. הצפנה באמצעות מפתח ציבורי: הצד השולח (א') מצפין את המידע באמצעות המפתח הציבורי של הצד המקבל (ב'). הצד המקבל (ב') מפענח את המסר באמצעות המפתח הפרטי שלו (מאחר והמפתחות הם של המקבל (ב'), רק הוא יכול לפענח את המסר). הצפנה באמצעות מפתח פרטי: הצד השולח (א) מצפין את המידע באמצעות המפתח הפרטי שלו. הצד המקבל (ב') מפענח את המסר באמצעות המפתח הציבורי של השולח (א'). מאחר והמפתחות הם של השולח (א'), יכול המקבל (ב')להיות בטוח שהמסר אכן נשלח מהשולח, שכן רק לו יש את המפתח הפרטי להצפנה). ראש העמוד 6. אמצעי אבטחת מידע כפתרון טכני לבעיות משפטיות השימוש בתהליכים ממוחשבים ללא נייר (PAPER-LESS) מחייב שינויים תחיקתיים ומשפטיים. שינוי תחיקה הינם תהליך המתמשך על פני שנים, אך בעיה זו לא צריכה למנוע את הכנסת הטכנולוגיה החדשה. הרבה מאמצים מושקעים כדי למצוא פתרונות ביניים עד להליך הסופי של התחיקה. בעיות משפטיות הנובעות מיישום IDE הינן תוצאה ישירה של ביטול עבודת הניירת המסורתית. הבעיה העיקרית: הדרישה להכין, למסור, לשלוח או לשמור מסמכים כתובים על נייר וחתומים בכתב יד, מוגדרת ברוב החקיקות הלאומיות וקשורה לתקיפות הפעולה החוקית ודיני הראיות. כאשר משתמשים בהעברת הנתונים החתומים במושגים של מפתח הצפנה ציבורי, קבלת ההודעה שקולה למעשה לקבלת מסמך חתום. אך קיים הבדל אחד: כאשר מעבירים מסמך חתום בדרך כלל מועבר המקור. מקור זה נמצא בבעלות הצד המקבל. בהעברת הודעות, "המקור" נשאר אצל הצד השולח. במקרה זה קיים חשש לשינוי "המקור". למניעת חשש זה קיימות טכניקות מסויימות, אולם עדיין נשאלת השאלה האם הנתונים המאוחסנים במחשב מהווים ראיה משפטית. ראש העמוד 7. חתימה דיגיטלית חתימה דיגיטלית מהווה פתרון לבעיה של יצירת הודעה חתומה. דרישות מחתימה דיגיטלית 1. על החתימה הדיגיטלית להיות ייחודית בדיוק כמו חתימה ידנית (DEPENDENCE SIGNER) 2. שילוב של חתימה עם תוכן ההודעה בצורה כזו שלא יהיה ספק שהנתונים לא השתבשו (DATA-DEPENDENCE) 3. SEPARATE OPERATION - על פעולת החתימה להיות פעולה עצמאית ונפרדת כדי לתת לחותם את התחושה של מתן חוקיות למסמך - בעצם ביצוע פעולת החתימה. ראש העמוד 8. ראיות (EVIDENCE) השמוש במחשבים להעברת מידע, מעלה מספר בעיות משפטיות הנוגעות לדיני הראיות. המסמכים המקובלים כיום (מסמכי נייר) הינם קבילים בבית משפט כיוון שניתן לאמת אותם ולאתר שינויים וזיופים באמצעים שונים, למשל חתימה, עדות בעל פה או בדיקת מומחים. מבחינת החוק, מידע ממוחשב, לרוב, אינו מהווה תחליף למסמכי נייר כיוון שבדרך כלל הינו מאוחסן על גבי אמצעי איחסון שניתן גם לקרוא מהם וגם לכתוב עליהם, כלומר, יש אפשרות להשמיד או לשנות את המידע מבלי להשאיר עקבות. קיימים פתרונות טכניים, אשר עונים על בעיית קבילות המידע הממוחשב כאמצעי ראיה בבית משפט: LOGGING .1 רישום מלא של ההודעות הנכנסות והיוצאות. כאשר רישום כזה נעשה ע"י צד (נייטרלי) שלישי (כגון: המתג הקהילתי), הערך הראייתי של רישום כזה עולה. רישום מלא בשני קצוות של השידור משפר את המצב (במיוחד מהסיבה שההודעות נושאות את חתימת הזמן בדיוק של שניות). 2. הדפסות הדפסות רציפות מהוות דרך לספק רישום שיש לו ערך ראייתי מסויים. ערך זה עולה כאשר משלבים את ההדפסות עם LOGGING . 3. סיסמאות ניתן לספק לשולח מילת קוד שבלעדיה לא יורשה לשלוח את ההודעה. מילת קוד זו יכולה לכלול בתוכה גם הגדרת סוג ההודעה המותרת לשליחה ע"י השולח. ניתן ליישם את פרוצדורת הסיסמאות בדרכים שונות: א. מהצד השולח נשלח שידור המראה על רצון ליצור קשר. הצד המקבל יוזם שידור לעבר הצד השולח, ורק לאחר מכן הצד השולח מעביר את ההודעה. שיטה זאת נועדה למנוע רמאות והתחזות בצורה של גניבת PASSWORDS. ב. שיטה שניה מצריכה LOGGING בשני הקצוות. בסוף ההודעה הצד השולח מעביר לצד המקבל את נתוני יומן ה- LOG שלו. הצד המקבל מאשר את קבלת ההודעה בכך שהוא שולח לעבר הצד השולח את נתוני יומן ה- LOG שלו. רק לאחר גמר התהליך כולו ההודעה הופכת להיות חוקית ותקפה. 4. פרוטוקולים: מושג זה בהעברת הנתונים משמש להגדרת כללים מוסכמים, למשל, צורת הצגת הנתונים בהודעה מסויימת, צורת הקמת הקשר ברשת תקשורת נתונה וכו'. פרוטוקולים חשובים ביותר לשותפים במסחר מתייחסים למבנה ההודעות (תחביר), הצגת הנתונים ( DATA ELEMENTS ( והתוים בהם משתמשים )אותיות גדולות או קטנות, אותיות לטיניות או קיריליות וכו'). שימוש בפרוטוקולים מעלה את הערך הראייתי של ההודעות המועברות. במקרה וישנה שגיאה, ההודעה נידחת. 5. אישור: אמצעי אבטחה הנותן לצד השולח ביטחון שהצד המקבל אכן קיבל את ההודעה. תגובת אישור יכולה להיות פשוטה אבל ברוב המקרים מומלץ לכלול בתוכה חלקים חשובים מההודעה המקורית. להבטחת ביטחון מירבי, על הצד המקבל את הודעת האישור לבדוק אותה מול ההודעה המקורית שנשלחה על ידיו ובמקרה של אי התאמות, ליידע מיידית את הצד השני. ראש העמוד