[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2012001763A1 - 計算機システムの管理方法及びクライアントコンピュータ - Google Patents

計算機システムの管理方法及びクライアントコンピュータ Download PDF

Info

Publication number
WO2012001763A1
WO2012001763A1 PCT/JP2010/061000 JP2010061000W WO2012001763A1 WO 2012001763 A1 WO2012001763 A1 WO 2012001763A1 JP 2010061000 W JP2010061000 W JP 2010061000W WO 2012001763 A1 WO2012001763 A1 WO 2012001763A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
information
monitoring module
destination
management
Prior art date
Application number
PCT/JP2010/061000
Other languages
English (en)
French (fr)
Inventor
智唯 内藤
信 萱島
晋一 角尾
洋 中越
礒川 弘実
則夫 鈴木
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US12/934,235 priority Critical patent/US9124616B2/en
Priority to PCT/JP2010/061000 priority patent/WO2012001763A1/ja
Priority to JP2012522369A priority patent/JP5417533B2/ja
Publication of WO2012001763A1 publication Critical patent/WO2012001763A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164File meta data generation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/554Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/535Tracking the activity of the user

Definitions

  • Patent Document 1 As an operation detection system that detects a malicious operation or a suspicious operation.
  • an administrator user creates a malicious operation pattern in advance and registers it in the database of the log analysis server, and then matches the contents of the user operation log recorded in advance. Judge the danger according to the degree.
  • the present invention uses information on the operation history of a file as additional meta information.
  • the additional meta information is stored in a predetermined storage area in the file or another area outside the file.
  • the meta information can include file storage identification information given when the file is stored in the file system of the client computer, operation generation identification information indicating the number of operations, and copy number information indicating the number of copies. .
  • meta information is created and associated with the destination file.
  • the meta information is also sent to and stored in the management device. Based on the meta information held by the management apparatus, the operation history of the file can be detected and displayed.
  • the present invention includes an unauthorized operation detection system for detecting unauthorized file operations.
  • the unauthorized operation detection system includes a monitoring device and a management terminal.
  • the monitoring device monitors operations on information on the screen of the output device connected to the monitoring target, with the microprocessor of the client computer as the monitoring target.
  • the management terminal manages the monitoring result of the monitoring device with the monitoring device as a management target.
  • the monitoring device In response to an operation for inputting information to the monitoring target, the monitoring device identifies the acquisition source of the input information input to the monitoring target and assigns an identifier indicating the acquisition source of the input information to the input information.
  • the output destination of the output information output from the monitoring target is identified, the identifier indicating the source of the output information is searched, and the identified output information It is determined whether or not the combination of the output destination and the source from which the retrieved output information is obtained meets the conditions for the unauthorized operation, and an alert is generated according to the determination result.
  • FIG. 6 is a diagram illustrating an example of a sequence executed between a user operation, a dialog operation monitoring module, a browser monitoring module, and a file operation monitoring module when a file is imported by a Web browser.
  • FIG. 14 shows how meta information (in-file trace information) is generated in accordance with a file operation according to the second embodiment of the present invention.
  • FIG. 24 shows a state in which a copy operation is performed from the state shown on the right side.
  • FIG. 25 shows a state where the file name has been changed from the state shown on the right side.
  • FIG. 26 shows a state where the file has been moved from the state shown on the right side.
  • FIG. 27 shows a state where a file is deleted from the state shown on the right side.
  • An example of tracing file operations based on information stored in the management server is shown.
  • An example of in-file trace information is shown. The sequence which monitors the file operation by a user is shown. It is a flowchart which shows the process which creates or updates in-file trace information.
  • the table for converting a count value into a character code is shown.
  • a state in which a character code is added to the last digit of the operation identifier when the number of times of copying reaches a predetermined number of times of copying is shown. If the file is illegally operated after the number of operations (number of operation generations) reaches the predetermined number of operations, the number of digits of the operation identifier is set to the upper limit value.
  • the file operation history is displayed in a tree structure.
  • a part of a database used for tracking an operation history such as a file attached to an e-mail is shown.
  • a state in which an operation history of a file attached to an e-mail is displayed in a tree structure is shown.
  • a configuration example of a client computer according to the third embodiment is shown.
  • the configuration of the agent program is shown.
  • the monitoring sequence in the case of downloading a file using a web browser is shown.
  • the monitoring sequence in the case of uploading a file using a web browser is shown.
  • the monitoring sequence in the case of receiving an electronic mail is shown.
  • the monitoring sequence in the case of transmitting an e-mail is shown.
  • Fig. 2 shows a part of a database used for monitoring the operation history of a file downloaded via a web browser.
  • Fig. 2 shows a part of a database used for monitoring the operation history of files uploaded via a web browser.
  • a part of the database used for monitoring the operation history of a file attached to a transmitted e-mail is shown.
  • history of operation of a file is shown.
  • the operation contents of an application program running on a client PC are monitored, the source of the input information input to the client PC is identified, and the input information includes First means for assigning an identifier indicating the source of input information, and identifying the output destination of the output information output from the client PC, inspecting the identifier assigned to the output information, It has a 2nd means which produces
  • FIG. 1 is a system configuration diagram showing an embodiment of the unauthorized operation detection system of the present invention.
  • a LAN (LOCAL Area Network) 117 in an information center 101 and a network 124 in a base 102 are connected by a wide area network 103, and the information center 101 is further connected to the Internet via the wide area network 104. It is assumed that it is connected to
  • the unauthorized operation detection system includes a management server 111 installed in the information center 101 and a client PC 121 installed in the base 102.
  • the management server 111 uses the information center 101 and the base 102 as management areas. For example, a mail server 114, a file server 115, an in-house Web server 116, a client PC 121, and a network printer 123 are arranged in the management area. Etc. are managed, and these managed objects are managed.
  • a manager 112 that controls the entire unauthorized operation detection system and a disk 113 that stores a PC management DB (DataBase) used by the manager to manage a plurality of client PCs operate.
  • the management server 111 corresponds to “management terminal” and / or “management device”.
  • Each client PC 121 is composed of a microprocessor loaded with various application programs.
  • each client PC 121 is a monitoring target, and an agent 122 is operated as a monitoring device that monitors an operation on information on the screen of the output device connected to the monitoring target.
  • the client PC 121 is configured as a computer such as a personal computer, a portable information terminal, a mobile phone, or the like.
  • the user who uses the client PC 121 performs business using e-mail, Web server, file server, and the like. Therefore, in the information center 101, a mail server 114, a file server 115, and an in-house Web server 116 are installed and connected to the LAN 117. Further, an external web server 131 that can be accessed from the client PC 121 is connected to the Internet.
  • a network printer 123 used for printing is connected to the network 124 in the base 102.
  • the removable medium 125 such as a flash memory is a device that is excluded from the management target of the management server 111 and is processed as an inspection target.
  • FIG. 22 is a block diagram showing an example of the configuration of the management server 111 in the present invention.
  • the management server 111 includes a CPU (Central Processing Unit) 2201, a bus 2202, a memory 2203, a PC management DB 2204 in the disks 113 and 113, a network I / F 2205, a device I / F 2206, an input device 2208, and a display device 2209.
  • the device I / F 2206 includes, for example, a USB (Universal Serial Bus) interface.
  • An OS (Operating System) 2207 is loaded on the memory 2203, and the manager program 112 is operating.
  • FIG. 2 is a block diagram showing an example of the configuration of the client PC 121 in the present invention.
  • the client PC 121 includes a CPU (Central Processing Unit) 201, a bus 202, a memory 203, a local file system 204, a network I / F 205, a device I / F 206, a disk 209, an input device 210, and a display device 211.
  • the device I / F 206 includes, for example, a USB (Universal Serial Bus) interface.
  • An OS (Operating System) 207 is loaded on the memory 203.
  • a program of agent 122 which is a component of the unauthorized operation detection system, and a plurality of application programs such as file explorer, Web browser (may be abbreviated as browser), mailer, word processor or spreadsheet software (application and 208 is stored in the memory 203 and is operating.
  • application programs such as file explorer, Web browser (may be abbreviated as browser), mailer, word processor or spreadsheet software (application and 208 is stored in the memory 203 and is operating.
  • the user using the client PC 121 uses any one of the application programs 208 to attach a file attached to the mail addressed to the user who arrived at the mail server 114, or a file stored in the file server 115, or
  • the file registered in the in-house Web server 116 is stored as a local file in the local file system 204 in the disk 209 in the file system format of the client PC 121.
  • the file 209 stored in the local file system 204 may be exported to the outside of the client PC 121 using any of the application programs 208.
  • the file is copied to a removable medium connected to the device I / F 206 by using a file explorer, or is printed by the network printer 123 by using a print function of a word processor or spreadsheet software.
  • attach a file to the mail body created by the mailer send the file to other parties inside or outside the organization, or upload the file to a web server inside or outside the organization.
  • FIG. 21 is a diagram illustrating an example of a screen when the user operates the application on the client PC 121 to import a file.
  • a link On the Web browser screen (screen of the output device connected to the client PC 121) 2101 there is an area called a link.
  • a pointing device an input device such as a mouse connected to the client PC 121
  • a screen transition or the like is caused.
  • the mouse cursor is placed on the link character string 2102 and the left button is clicked, the next dialog (also called a page) is displayed, or the download dialog for downloading the target (file) at the clicked link destination Processing for displaying 2111 is executed.
  • a pop-up window called a context menu is displayed.
  • the context menu 2103 displayed here there is an item “save target in a file (A)...”. By left-clicking on this item, processing for displaying a download dialog 2111 for downloading the target is performed. Executed.
  • the download dialog 2111 includes a field 2112 indicating a location where the downloaded file is stored, a field 2113 displaying a selection of a save destination folder, and 2114 indicating a file name to be stored.
  • the file name to be saved can be rewritten.
  • the user operates the fields 2112 and 2113 to select a folder in which to save the file, changes the save file name in the field 2114 as necessary, and clicks the save button 2115, so that the file can be saved using a web browser. You can download and save the file in any folder.
  • FIG. 3 is a diagram showing an example of the module configuration of the agent 122 operating on the client PC 121.
  • the agent 122 includes a manager communication function module 301 that is responsible for communication with the manager 112 and a monitoring module control module 302 that controls various monitoring modules that monitor user operations on the client PC 121.
  • the agent 122 includes a process monitoring module 310, a printer monitoring module 320, a browser monitoring module 330, a dialog operation monitoring module 340, a file operation monitoring module 350, and a TCP communication monitoring module 360.
  • the process monitoring module 310 monitors the operation status of the application program 303 running on the client PC 121.
  • the printer monitoring module 320 monitors an output operation to the printer 304 including the network printer 123.
  • the browser monitoring module 330 monitors user operations by the web browser 305.
  • the dialog operation monitoring module 340 monitors various dialogs 306 displayed on the screen of the client PC 121 and used by the user to select a file when downloading or uploading.
  • the file operation monitoring module 350 uses a pointing device such as a mouse to operate the various applications 307 displayed on the screen (for example, button clicks or displayed in the application window). (E.g. drag and drop).
  • TCP communication monitoring module 360 for example, an application such as a mailer that transmits / receives data via a network transmits a data stream using a TCP / IP (Transmission Control Protocol / Internet Protocol) socket 308 or the like by a user operation. Monitor the reception status.
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • the agent 122 has a system policy 391 that is a setting file for controlling the operation of the module, and a security policy 392 that is a setting file for performing control related to security in particular, and the monitoring module group described above.
  • a system policy 391 that is a setting file for controlling the operation of the module
  • a security policy 392 that is a setting file for performing control related to security in particular, and the monitoring module group described above.
  • the process monitoring module 310 suppresses the activation when the activation detection function 311 that detects that the activation of the process 303 is requested on the client PC 121 and the activated process 303 violates the security policy 392.
  • a suppression function 312 and a user notification function 313 for notifying the user that activation has been suppressed are realized.
  • the printer monitoring module 320 suppresses printing when the print detection function 321 that detects that printing using the printer 304 is requested on the client PC 121 and the data to be printed violate the security policy 392. And a user notification function 323 for notifying the user that activation has been suppressed.
  • the browser monitoring module 330 has an access detection function 331 for detecting that the client PC 121 has accessed the Web server using the browser 305, the URL (Uniform Resource Name) of the accessed Web server, and the received html (Hypertext Markup Language).
  • the detection content holding function 332 that temporarily holds data and the like is realized.
  • the dialog operation monitoring module 340 uses a dialog detection function 341 that detects that a file selection dialog or a print dialog is displayed when the user operates the application program 208 on the client PC 121, and the dialog. It provides an acquisition source information addition / inspection function 342 that assigns information about the source of the file to the operated file and checks the information about the source of the file that has been assigned.
  • the operation to display the file selection dialog is, for example, an operation to download or upload a file using a web browser, an operation to save an attached file from a received mail using a mailer, or an attachment to a sent mail There is an operation to do.
  • the operation for displaying a print dialog corresponds to an operation for selecting a print function using a word processor or spreadsheet software.
  • the file operation monitoring module 350 is an operation detection that detects that a mouse button click operation or an operation such as dragging and dropping an object displayed in the window is performed on the window of the application program 208 on the client PC 121. Realization of the function 351 and the source information addition / inspection function 352 that assigns information about the source of the file to the file operated with the mouse, and performs inspection of the information about the source of the file assigned To do.
  • the file operation by clicking the mouse button is, for example, an operation of right-clicking a link displayed on the screen of the web browser and saving the object indicated by the link as a file in the displayed menu or a mailer. Drag and drop a file attached to the received message screen to copy it to the desktop.
  • the TCP communication monitoring module 360 has a socket reception detection function 361 for detecting that a file is transmitted / received via a network as a result of a user performing an operation with a network application on the client PC 121 ⁇ ⁇ ⁇ , and transmitting / receiving via the socket.
  • a socket reception detection function 361 for detecting that a file is transmitted / received via a network as a result of a user performing an operation with a network application on the client PC 121 ⁇ ⁇ ⁇ , and transmitting / receiving via the socket.
  • Each monitoring module described above has a function of communicating with another monitoring module or the acquisition source DB 393 according to the detected content, and a function of transmitting an alert to the manager 112 via the monitoring module control 302 and the manager communication mechanism 301. And a function of generating an alert and / or detection content log.
  • information relating to the present invention will be described using expressions such as information relating to files.
  • these pieces of information may be expressed by other than a data structure such as a table. Therefore, in order to show that the information does not depend on the data structure, “information about the file” may be simply referred to as “information”.
  • information about the file may be simply referred to as “information”.
  • the description as a DB may be simply referred to as “information”.
  • program is used as the subject, but the program is executed by the processor to perform a predetermined process using a memory and a communication port (communication control device). Therefore, the description may be made with the processor as the subject. Further, the processing disclosed with the program as the subject may be processing performed by a computer such as the management server 111 or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware. Further, the present invention is not necessarily realized by using a thread mechanism, and any mechanism may be used as long as it can be executed by a mechanism that manages execution of a program provided by the OS, such as a micro thread or a process mechanism.
  • various programs may be installed in each computer by a program distribution server or a storage medium.
  • the management computer 111 has an input / output device.
  • the input / output device include a display, a keyboard, and a pointer device, but other devices may be used.
  • a serial interface or an Ethernet interface is used as an input / output device, a display computer having a display, keyboard, or pointer device is connected to the interface, and display information is displayed on the display computer.
  • the input and display on the input / output device may be substituted by receiving the input.
  • FIG. 4 is an example of a sequence showing a flow of processing executed by the browser monitoring module 330 and the dialog operation monitoring module 340 when the user downloads a file with a Web browser.
  • a page transition user operation event occurs in the web browser, and the browser monitoring module 330 detects the page transition user operation event ( 402).
  • the browser monitoring module 330 stores the URL after the transition (that is, the URL of the clicked link destination object) and waits for an information provision request from the dialog operation monitoring module 340 (403).
  • a file download dialog is displayed.
  • the dialog operation monitoring module 340 detects a dialog operation event (404), requests the browser monitoring module 330 to provide post-transition URL information, and then the browser monitoring module. Obtain post-transition URL information from 330 (405).
  • the dialog operation monitoring module 340 obtains the save destination file name from the information displayed in the dialog (information by processing of the OS 207), and uses the full path as the save destination information of the file. Is obtained (406). Further, when the server included in the post-transition URL acquired in step 405 is the intra-organization Web server 116, the dialog operation monitoring module assigns an identifier indicating the acquisition source to the file (407). This identifier can be realized using an “alternate stream” when NTFS (NT File System) of Microsoft (registered trademark) is used as the local file system 204 used by the client PC 121.
  • NTFS NT File System
  • Microsoft registered trademark
  • FIG. 5 is an example of a sequence showing a flow of processing executed by the browser monitoring module 330, the dialog operation monitoring module 340, and the file operation monitoring module 350 when the user downloads a file with a Web browser.
  • the browser monitoring module 330 detects a user operation event of page transition (501). At this time, the Web browser holds the URL and page source after the transition, and can pass them in response to a request from the browser monitoring module 330.
  • the user performs a right click operation on the link displayed on the Web browser in this state (503), a mouse operation event occurs, and the file operation monitoring module 350 detects the event (505).
  • the file operation monitoring module 350 stores the information related to the position where the mouse operation event has occurred on the Web browser as object related information and sends it to the browser monitoring module 330 (506).
  • the browser monitoring module 330 stores the URL of the page after the transition and the page source each time the page is displayed on the Web browser (502).
  • the dialog operation monitoring module 340 detects the dialog display event (507), it acquires the URL and page source (page data) of the displayed page from the browser monitoring module 330 (508). Further, the dialog operation monitoring module 340 obtains the file path where the file is stored (510), and if the server included in the URL of the file is the in-house Web server 116, the file source is monitored. As an object, an identifier indicating the acquisition source is assigned to the file (511).
  • FIG. 6 is an example of a sequence showing a flow of processing executed by the TCP communication monitoring module 360 and the dialog operation monitoring module 340 when the user saves the file attached to the mail in the local system 204 by the mailer.
  • a message is downloaded from the mail server 114.
  • the TCP communication monitoring module 360 that monitors the socket in the network driver or the TCP / IP protocol stack performs the analysis processing of the mail body data (603), and acquires the sender name and the attached file name in the message. (604).
  • the TCP communication monitoring module 360 decodes the attached file data encoded with Base64 or the like, and calculates a hash value (605).
  • the attached file name, hash value, and attached file sender name obtained in steps 604 and 605 are registered in the source DB 393 (606).
  • the user may attempt to perform an operation to save the attached file in the local file system 204 while browsing the mail text using the mailer (this operation is not performed immediately after downloading the mail data). , May be executed after a considerable amount of time).
  • the dialog operation monitoring module 340 detects the dialog display event (607), and obtains the file name from the information displayed in the dialog. (608) and obtain the full path of the file storage destination (609). Further, the obtaining source DB 393 is searched using the file name displayed in the dialog as a key, and attributes such as the sender name of the file are obtained (610).
  • the attached file name is a general name, for example, “specifications.doc”
  • a plurality of records may be registered in the source DB 393.
  • it is possible to obtain the sender name of the file by calculating a hash value for the file having the storage destination file name obtained in step 608 and searching the obtaining source DB 393 using the hash value as a key. Is possible.
  • step 610 if the sender of the file is another user in the organization, an identifier indicating the source is given to the file (611).
  • FIG. 7 is an example of a sequence showing a flow of processing executed by the TCP communication monitoring module 360 and the file operation monitoring module 350 when the user saves the file attached to the mail in the local file system 204 by the mailer. .
  • step 701 to step 706 is the same as the sequence in FIG. 6 (step 601 to step 606). While the user is viewing the mail text using the mailer, the operation to save the attached file to the local file system 204 is not only performed using the file save dialog but also displayed on the mailer screen. There is also a method of dragging and dropping an icon indicating the attached file to the desktop or file explorer.
  • the file operation monitoring module 350 detects a drag-and-drop event with the mouse from the mailer screen (707). Further, the file operation monitoring module 350 monitors a file generation event for the file system, obtains the name of the file generated in the local file system 204 in response to the drag and drop operation by the mouse (708), and displays the full path. Obtain (709), search the source DB 393 using the file name and the hash value of the file as a key, and obtain attributes such as the sender name of the file (710). If the sender of the file is another user in the organization in step 710, an identifier indicating the source is given to the file (711).
  • FIG. 8 is an example of a sequence showing a flow of processing executed by the browser monitoring module 330 and the dialog operation monitoring module 340 when a user uploads a file using a Web browser.
  • the dialog operation monitoring module 340 detects the event in which the file selection dialog is displayed, acquires the name of the selected file, and starts monitoring the file open (805).
  • the browser monitoring module 330 detects a page transition event that occurs as a result (803), and stores the URL after the transition (804).
  • the dialog operation monitoring module 340 detects a file open for the corresponding file (806), and acquires the file path of the corresponding file from the OS 207 (807).
  • the dialog operation monitoring module 340 determines whether or not the alert condition is satisfied, and transmits the alert to the manager 112 when it is determined that the alert condition is satisfied (809).
  • the dialog operation monitoring module 340 acquires the URL after the page transition from the browser monitoring module 330, determines whether the output destination of the file is the inspection target, and the Web server that uploaded the file is a server outside the organization. If there is, it is determined that the output destination of the file is the inspection target, and the identifier of the file acquisition source is confirmed.
  • a file copied from the file server 115 in the organization, a file downloaded from the web server 116 in the organization, or a file acquired by being attached to the mailer is a file to be uploaded. If so, an alert is output (809).
  • the process of outputting an alert is a process of transmitting an alert to the manager 112 of the management server 111 when a predetermined alert condition is met.
  • the predetermined alert condition is set so that an alert is transmitted when a file upload destination server is a monitoring target such as the non-organizational Web server 131 and the upload target file is a management target.
  • the output destination of the output information output from the client PC 121 that is, for example, when the Web server that uploaded the file is the non-organization Web server 131, the Web server 131 is an inspection target different from the management target of the management server 111 .
  • Files managed by the management server 111 include, for example, (1) a file copied from the file server 115 in the organization and (2) a file downloaded from the web server 116 in the organization. (3) A file corresponding to one of the files acquired by being attached to the mailer.
  • the output information (file) output from the client PC 121 is determined to be information generated by an unauthorized operation.
  • an alert indicating that the operation condition (alert condition) is met is generated, and the alert is transmitted to the management server 111.
  • the management server 111 determines that an unauthorized operation with a high risk leading to an information leakage accident has been detected, and manages information associated with the unauthorized operation as information to be processed with an alert. As a result, the administrator can execute a countermeasure for suppressing information leakage based on the alert collected by the management server 111.
  • FIG. 9 is an example of a sequence showing a flow of processing executed by the TCP communication monitoring module 360 and the dialog operation monitoring module 340 when the user transmits an email with an attached file using the mailer.
  • the dialog operation monitoring module 340 detects a display event of the file selection dialog (906) and is selected. Get the name of the file and the full path of the file (907) and wait until the mail is sent.
  • the TCP communication monitoring module 360 analyzes the data sent using the SMTP (Simple Mail Transfer Protocol) protocol (903), and sends the destination and attachment.
  • the file name is acquired (904).
  • the TCP communication monitoring module 360 sends the mail to the destination dialog operation monitoring module 340 to a destination outside the organization. (905).
  • the dialog operation monitoring module 340 confirms the identifier indicating the source of the sent file, and the file copied from the file server in the organization, the file downloaded from the web server in the organization, or attached to the mailer If the file is one of the acquired files, an alert is output (908).
  • FIG. 10 is an example of a sequence showing a flow of processing executed by the TCP communication monitoring module 360 and the file operation monitoring module 350 when the user transmits an email with an attached file using the mailer.
  • the file operation monitoring module 350 drags and drops the file from the file explorer or the like to the mailer window. Is detected (1006), the name of the selected file and the full path of the file are acquired (1007), and the system waits until an email is sent.
  • the TCP communication monitoring module 360 analyzes the data transmitted by the SMTP protocol (1003), and acquires the transmission destination and the attached file name ( 1004).
  • the TCP communication monitoring module 360 sends the mail to the destination dialog operation monitoring module 340 to a destination outside the organization. (1005)
  • the file operation monitoring module 350 confirms the identifier indicating the source of the sent file, and the file copied from the file server in the organization, the file downloaded from the web server in the organization, or attached to the mailer If it is one of the acquired files, an alert is output (1008).
  • FIG. 11 is an example of a sequence showing a flow of processing executed by the dialog operation monitoring module 340 when a user performs a printing operation with an application.
  • the dialog operation monitoring module 340 detects a display event of the print dialog (1103), and acquires the window title of the application that performs printing (1104). As a result, the dialog operation monitoring module 340 acquires the full path of the file that is opened by the application and is about to be printed (1105).
  • the dialog operation monitoring module 340 detects that the dialog is closed (1206), and confirms the identifier indicating the source of the transmitted file. If the file is copied from the file server in the organization, downloaded from the web server in the organization, or obtained by attaching to the mailer, an alert is output (1107). ).
  • Fig. 12 shows two sequences.
  • the first means realized by the process executed by the file operation monitoring module 350 when the user copies the information of the file server 115 to the local file system 204 using the file explorer.
  • the sequence is shown.
  • a lower part of FIG. 12 shows a sequence of second means realized by processing executed by the file operation monitoring module 350 when the user copies a file to a removable medium using the file explorer. ing.
  • the file operation monitoring module 350 specifies a file copy source and a copy destination (1202). If the copy source is the file server 115 and the copy destination is the client PC 121, the file operation monitoring module 350 assigns an identifier indicating the acquisition source to the operation target file (1203).
  • the file operation monitoring module 350 identifies a file copy source and a copy destination (1212).
  • the copy source is the local file system 204 of the client PC 121 and the copy destination is a removable medium connected to the client PC 121
  • the file operation monitoring module 350 sets an identifier indicating the acquisition source in the operation target file.
  • the operation target file is either a file copied from within the organization, a file downloaded from a web server in the organization, or a file acquired by attaching to a mailer.
  • an alert is output (1213).
  • FIG. 13 shows an example of the format of the acquisition source DB 393 used for storing information about received mail and the identifier 1311 indicating the acquisition source assigned to the file stored in the local file system 204.
  • the acquisition source DB 393 includes a field 1301 for storing the file name, a field 1302 for storing the sender name of the mail, and a field 1303 for storing the hash value of the file described in the field 1301.
  • the identifier 1311 indicating the acquisition source can be realized as data in the ini file format using “alternate stream” in the case of Microsoft NTFS. If the file is obtained from the mail server 114, the sender's mail address is described in the From line. If the file is obtained from the file server 115, the server name or IP address of the file server is described in the Server line. If it is a file obtained from an internal Web server, the URL indicating the obtained file is described. Unused lines may be erased, or after the equal may be blank.
  • the content included in the identifier 1311 indicating the source can be transmitted to the management server 111 as an alert by the second means.
  • the acquisition date and time can also be included in the contents of the alert.
  • a time information field for storing the time when the mail including the attached file is received may be added as a field of the source DB 393.
  • the TCP communication module 360 registers the reception time described in the mail header in the time information field, and in steps 610 and 710 for acquiring file attributes, also acquires the recording time of the time information field,
  • the configuration may be such that time information is given to the acquisition source identifier 1311.
  • FIG. 14 is an example of a flowchart showing an outline of processing executed by the browser monitoring module 330.
  • the browser monitoring module 330 is started when the Web browser is started, sets the monitoring of user operation events for the Web browser described in FIGS. 4, 5, and 8 (1401), and determines whether an event has occurred. Enter the loop (1402). When the occurrence of an event is detected, the browser monitoring module 330 executes a step of determining whether or not the page has been changed by the user's left click operation (1403).
  • the browser monitoring module 330 executes the step (1404) of transmitting the URL to the dialog monitoring module 340 after executing the step (1404) of acquiring the URL after the transition. To do.
  • the browser monitoring module 330 executes a step (1405) of acquiring coordinate information on the browser of the mouse event from the file operation monitoring module 350.
  • the browser monitoring module 330 executes a step (1406) of acquiring an HTML anchor tag positioned under the mouse cursor, and executes a step (1407) of extracting a URL selected by the mouse cursor.
  • the buzzer monitoring module 330 executes a step (1404) of transmitting a URL to the dialog monitoring module 340.
  • FIG. 15 is an example of a flowchart showing an outline of processing executed by the dialog operation monitoring module 340.
  • the dialog operation monitoring module 340 is activated when the user logs on to the client PC 121.
  • the dialog operation monitoring module 340 monitors file operations using the dialog described in FIGS. 4, 5, 6, 8, 9, and 11. For example, a setup (1501) such as timer monitoring is performed. After doing so, monitor the event for which the dialog appears (1502).
  • the dialog operation monitoring module 340 checks whether an upload dialog or a download dialog is displayed (1503). If any dialog is displayed, the dialog is displayed. Determine the type of the application (1504). If the application is a mailer, a step (1505) of generating a mailer check thread is executed, and if it is a Web browser, a step (1506) of generating a Web browser check thread is executed.
  • step 1503 if the displayed dialog is neither an upload dialog nor a download dialog, the dialog operation monitoring module 340 determines whether the displayed dialog is a print dialog (1507). . In the case of a dialog for printing, the dialog operation monitoring module 340 performs a step (1508) of generating a print check thread.
  • the dialog operation monitoring module 340 After executing the step of generating each thread, the dialog operation monitoring module 340 returns to the step (1502) of monitoring the event in which the dialog is displayed.
  • FIG. 16 is an example of a flowchart showing an outline of the mailer check thread generation step 1505 in the processing executed by the dialog operation monitoring module 340.
  • the dialog operation monitoring module 340 checks whether either the upload dialog or the download dialog is displayed (1601), and if any dialog is displayed, it is displayed in the dialog.
  • the folder name is acquired from the character string (1602) and the file name is acquired (1603).
  • the dialog operation monitoring module 340 configures the full path of the file to be uploaded or downloaded (1604), and returns to Step 1601.
  • step 1611 when the user clicks a dialog save button or the like to hide the dialog, the processing from step 1611 is executed.
  • the dialog operation monitoring module 340 determines whether a full path has been acquired in step 1604 and a file indicated by the full path exists (1611). The dialog operation monitoring module 340 executes the processing from step 1612 onward when the file exists, and returns to step 1601 when the file does not exist.
  • the dialog operation monitoring module 340 first determines whether it is a download dialog (1612), and if it is a download dialog, calculates the hash value of the file specified in step 1604 (1613). . As shown in FIGS. 6 and 7, the dialog operation monitoring module 340 searches the information registered in the acquisition source DB 393 by the TCP communication monitoring module 360 (1614), and the acquisition source is another user in the organization. If the predetermined condition is met, the acquisition source information is written in the file specified by the full path acquired in step 1604 (1609).
  • the dialog operation monitoring module 340 receives the destination information from the TCP communication module 360 (1621) as shown in FIGS. 9 and 10, and the file specified in the upload dialog is attached to the mail. If it is transmitted, the source information of the file specified in step 1604 is read (1622). The dialog operation monitoring module 340 checks the alert condition, generates an alert, and transmits the alert to the management server 111 as necessary (1623).
  • FIG. 17 is an example of a flowchart showing an outline of the Web browser check thread generation step 1506 among the processes executed by the dialog operation monitoring module 340.
  • the dialog operation monitoring module 340 checks whether either the upload dialog or the download dialog is displayed (1701), and if any dialog is displayed, it is displayed in the dialog.
  • the folder name is acquired from the character string (1702) and the file name is acquired (1703), the full path of the file to be uploaded or downloaded is configured (1704), and the process returns to step 1701. Thereafter, when the user clicks a dialog save button or the like to hide the dialog, the processing from step 1705 is executed.
  • the dialog operation monitoring module 340 determines whether a full path has been acquired in step 1704 and a file indicated by the full path exists (1705). The dialog operation monitoring module 340 executes the processing from step 1706 if the file exists, and returns to step 1701 if the file does not exist.
  • the dialog operation monitoring module 340 first determines whether or not it is a download dialog (1706). If the file is a download dialog, the browser monitoring module 330 displays the download dialog as shown in FIGS.
  • the download source information to be held is obtained (1707), and if the obtained source matches with a predetermined condition such as being another user in the organization, the obtained source information is written in the file indicated by the full path acquired in step 1704 ( 1708).
  • the dialog operation monitoring module 340 obtains the upload destination information held by the browser monitoring module 330 from the browser monitoring module 330 as shown in FIG. 8 (1709).
  • the dialog operation monitoring module 340 reads the source information of the file specified by the full path acquired in step 1704 (1710), and whether or not the alert condition is met. An alert is generated by checking and an alert is transmitted to the management server 111 as needed (1711).
  • FIG. 18 is an example of a flowchart showing an outline of step 1508 of generating a print check thread by the application among the processes executed by the dialog operation monitoring module 340.
  • the dialog operation monitoring module 340 checks whether the print dialog is displayed (1801). If the dialog is displayed, the process ID of the application program of the print source is acquired (1802). Further, the file name is acquired from the list of files opened by the application program specified by the process ID (1803). The dialog operation monitoring module 340 configures the full path of the file to be printed (1804) and returns to step 1801.
  • the dialog operation monitoring module 340 reads the source information of the file to be printed (1805), checks the alert condition, and sends an alert. Generate and send an alert to the management server 111 as needed (1806).
  • FIG. 19 is an example of a flowchart showing an outline of processing executed by the file operation monitoring module 350.
  • the file operation monitoring module 350 is activated when the user logs on to the client PC 121, starts a mouse event hook (1901), and then performs the file operation using the mouse described in FIGS. Monitor. When detecting the event, the file operation monitoring module 350 determines whether or not the detected mouse operation event is a right click (1902).
  • the file operation monitoring module 350 obtains the mouse cursor coordinates in the foreground window (1903), executes conversion processing to the browser window coordinates (1904), and sends the browser monitoring module 330 to the step 1904. Processing for notifying the acquired coordinates is executed (1905), and the process returns to event monitoring.
  • step 1902 if it is determined in step 1902 that the mouse operation event is not a right click, the file operation monitoring module 350 executes processing for determining whether it is a drag event (1911). Returns to event monitoring.
  • the file operation monitoring module 350 detects an event where the dragged object is dropped, and determines whether the dragged file is dropped on the mailer (1912). ).
  • step 1912 the file operation monitoring module 350 proceeds to step 1921 described later. If YES in step 1912, the file operation monitoring module 350 acquires the drag source file path (1913), reads the source information of the file specified by the full path acquired in step 1913 (1914), and alerts. After checking the conditions, an alert is transmitted to the management server 111 as necessary (1915).
  • step 1912 If it is determined in step 1912 that the object is dropped on the mailer, the file operation monitoring module 350 determines whether the drag and drop event is dragged on the mailer and dropped on the file explorer (1921).
  • step 1921 is determined to be No, the file operation monitoring module 350 returns to event monitoring. If it is determined to be Yes in step 1921, the file operation monitoring module 350 acquires the file path to which the file attached to the email is dropped ( 1922). Next, the file operation monitoring module 350 calculates the hash value of the file from which the full path is acquired in Step 1922 (1923), and searches the information registered in the acquisition source DB 393 (1924). The file operation monitoring module 350 writes the acquisition source information in the file indicated by the full path acquired in step 1922 when the acquisition source matches a predetermined condition such as when the acquisition source is another user in the organization (1915).
  • processing of the file operation monitoring module 350 for the sequence shown in FIG. 12 is also performed in accordance with steps 1922 and 1925 when the drag source is the file server 115 and the drop destination is the local file system 204. Is the local file system 204 and the drop destination is a removable medium, the processing according to steps 1913 and 1915 may be performed.
  • step 1915 may be performed.
  • FIG. 20 is an example of a flowchart showing an outline of processing executed by the TCP communication monitoring module 360.
  • the TCP communication monitoring module 360 is activated when the user logs on to the client PC 121, and monitors communication data in each protocol of SMTP, POP3, and IMAP4.
  • the TCP communication monitoring module 360 starts monitoring socket communication (2001), and determines whether the data is transmission / reception data in any of the above protocols (2002). If Step 2002 is No, the process returns to the monitoring of socket communication. If Yes, the processes after Step 2003 are performed.
  • the TCP communication monitoring module 360 analyzes mail data.
  • the sender and recipient information can be analyzed from the header area of the mail data, and further information such as the presence / absence of an attached file and the file name can be obtained by analyzing the MIME (Multipurpose Internet Mail Extension) part.
  • MIME Multipurpose Internet Mail Extension
  • the TCP communication monitoring module 360 identifies whether there is an attached file in the mail (2004), and if it is attached, the protocol type is either POP3 or IMAP4 for receiving mail, or It is determined whether it is SMTP for mail transmission (2005). In the case of mail reception, the TCP communication monitoring module 360 obtains the sender name and the attached file name (2006), decodes the attached file data, calculates the hash value (2007), and further sends it to the source DB 393. After registering, return to monitoring socket communication.
  • the TCP communication monitoring module 360 acquires the sender name and the attached file name (2009), and acquires them in the dialog monitoring module 350 and the file monitoring module 360 in step 2009. Send the information (2010).
  • the source is also indicated in the post-processing information (including the copied information)
  • the file system for example, Microsoft's NTFS
  • the file system for example, Microsoft's NTFS
  • Sending emails with attached files (3) Printing with application programs, (4) Copy and move to removable media, Can be sent to the management server 111.
  • the alert condition for sending an alert using this system may be determined based on the content of the identifier 1311 indicating the source. For example, if the information is imported by downloading using a Web browser, all Web servers in the organization may be targeted, or if the Web server storing important information can be identified It may be set in the security policy 392 so that only the case where the URL of the Web server is included in the identifier 1311 indicating the acquisition source.
  • the operation exported outside the organization can be detected as an unauthorized operation. Is possible. Therefore, in this embodiment, an operation with a high risk that leads to information leakage performed by the user can be detected as an unauthorized operation.
  • in-file trace information for managing the history of file operations is stored in each file, and the same information as the in-file trace information is also stored in the management server 111.
  • management server 111 stores the management server 111.
  • FIG. 23 shows how in-file trace information is generated.
  • the in-file trace information is, for example, information indicating which generation of what generation of which file is copied, and is recorded in, for example, an NTFS alternative data stream (hereinafter referred to as an alternative stream).
  • an alternative stream an NTFS alternative data stream
  • the file creation is detected by the file operation monitoring module 350.
  • the file operation monitoring module 350 creates in-file trace information (3001).
  • the created in-file trace information is stored in an alternative stream of the file 3002.
  • the agent program 122 transmits the created in-file trace information to the manager 112.
  • the same information as the in-file trace information is also stored in the PC management DB (3101 in FIG. 29).
  • the in-file trace information includes, for example, a file storage identifier (FID), an operation identifier (OID), and a count.
  • the file storage identifier is information set when the file is stored in the file system 204 of the client PC 121, and is information for uniquely identifying the file.
  • the operation identifier corresponds to “operation generation information” and is information indicating the number of file operations (generation).
  • the count corresponds to “copy number information” and indicates the number of times the file has been copied. In other words, the count indicates the number of systems branched from the file.
  • the “count” shown in the file 3002 is also used to generate the next operation identifier.
  • the system increments by one each time it is copied, so the count value in the operation source file indicates the operation of the operation destination file to indicate the number of operations of the file of which system. Inherited by identifier.
  • the file operation monitoring module 350 acquires in-file trace information from the alternative stream of the file 3002, and creates in-file trace information after the copy operation (3003).
  • the created in-file trace information (3003) is stored in an alternative stream of the copy destination file 3004. Further, the same information as the in-file trace information is associated with the copy destination file and stored in the PC management DB.
  • the count value of the copy source file 3002 is updated from “0” to “1”. Copying a file means creating a new file having the same contents while leaving the copy source. That is, a plurality of files having the same contents coexist. Therefore, the count value is updated according to the number of copies, and the system for each copy is distinguished.
  • the file operation is a copy
  • the operation source file 3002 is a copy source file
  • the operation destination file 3004 is a copy destination file.
  • the copy source file 3002 and the copy destination file 3004 have the same file data. Accordingly, the file storage identifier of the copy source file 3002 and the file storage identifier of the copy destination file 3004 are the same.
  • the operation identifier of the copy source file 3002 is “0”.
  • the operation identifier of the copy destination file 3004 is “00”. Each time the number of operations increases by one, the number of digits of the operation identifier increases by one.
  • the operation identifier of the operation destination file is composed of the operation identifier and count of the operation source file.
  • the operation identifier of the operation source file 3002 is “0”, and the count is also “0”. Therefore, the operation identifier of the operation destination file 3004 is created as “00” by arranging the operation identifier “0” of the operation source file 3002 and the count “0” of the operation source file 3002.
  • the operation identifier indicates both the number of operations and the system (number of branches).
  • the number of digits of the operation identifier indicates the number of operations. Two digits indicate that this is the second operation.
  • the first operation is file creation.
  • a number (or character) other than “0” included in the operation identifier indicates how many times the copy is a descendant. For example, the file 3006 with the operation identifier “000” is a direct descendant of the file 3002 with the operation identifier “0”, and is a file created by the third operation.
  • the file operation in this case is a name change.
  • the operation source file is the file 3004 of the name change source (before the name change).
  • the operation destination file is the file 3006 of the name change destination (after the name change).
  • the file operation monitoring module 350 acquires the in-file trace information from the alternative stream of the file 3004, and creates the in-file trace information after the name change (3005).
  • the created in-file trace information (3005) is stored in an alternative stream of the renamed file 3006.
  • the same information as the in-file trace information is stored in the PC management DB in association with the name change destination file 3006.
  • the rename destination file 3006 has only the name changed, and has the same file data as the file 3004. Accordingly, the file storage identifier of the rename source file 3004 and the file storage identifier of the rename destination file 3006 are the same.
  • the operation identifier “000” of the rename destination file 3006 is generated by arranging the operation identifier “00” and the count “0” of the rename source file 3004. Since the operation identifier “000” of the name change source file 3006 has three digits, it can be seen that the file 3006 is a file created by the third operation counting from the creation of the file 3002 as the starting point. Note that “0” is set in the count of the name change destination file 3006.
  • the file operation here is file deletion.
  • the operation source file is the file 3006 to be deleted.
  • the operation destination file does not exist. This is because it is deleted.
  • the operation destination file does not exist, but in-file trace information 3007 for the operation destination file is created.
  • the file storage identifier is the same as the file storage identifier of the deletion target file 3004.
  • the operation identifier “0000” is created by arranging the operation identifier “000” and the count “0” of the deletion target file 3004.
  • the same information as the in-file trace information 3007 created for the operation destination file is stored in the PC management database.
  • the file operation is file movement
  • the operation source file is the movement source file 3002
  • the operation destination file is the movement destination file 3009.
  • the file operation monitoring module 350 detects the file movement
  • the file operation monitoring module 350 acquires the in-file trace information of the movement source file 3002, and creates the in-file trace information 3008 of the movement destination file 3009 based on the in-file trace information.
  • the file storage identifier is the same as the file storage identifier of the migration source file 3002.
  • the operation identifier “01” is generated by arranging the operation identifier “0” and the count “1” of the migration source file 3002. As described above, the initial value “0” is set for the count of the transfer destination file 3009.
  • the movement source file 3002 disappears and only the movement destination file 3009 remains in the file system 204.
  • in-file trace information 3001 related to the migration source file 3002 is continuously stored in the PC management DB.
  • the destination file 3009 is deleted.
  • the file operation in this case is file deletion, and the operation source file is the deletion target file 3009. Since the file is deleted, the operation destination file does not exist.
  • in-file trace information 3010 for the operation destination file is created and stored in the PC management DB.
  • the operation identifier “010” is generated by arranging the operation identifier “0” and the count “1” of the deletion target file 3002.
  • the count value of the in-file trace information 3010 is set to “0” that is an initial value.
  • FIG. 23 The file operation history described in FIG. 23 will be described again with reference to FIGS. 24-28, each file operation shown in FIG. 23 will be described one by one. However, only one duplicate file operation (file deletion) among the file operations shown in FIG. 23 is shown in FIGS.
  • FIGS. 24-28 show the relationship between in-file trace information and the contents stored in the PC management DB.
  • the left side of FIG. 24 shows an initial state. In the initial state, no file is stored in the file system 204 of the client PC 121, and no record is recorded in the PC management DB.
  • FIG. 24 shows a state where one file 3002 is stored in the file system.
  • files downloaded from the Web servers 116 and 131, files downloaded from the file server 115, files copied from the removable media 125, files attached to e-mails, and the like are stored in the file system. .
  • in-file trace information 3001 for the file is created.
  • “0” is set as the operation identifier, and the initial value “0” is also set as the count.
  • the PC management DB stores the same information as the in-file trace information 3001. Further, the contents of the file operation (information indicating where the file is obtained from) are also stored in the PC management DB.
  • the left side of FIG. 25 is the same as the right side of FIG. Therefore, the state on the right side of FIG. 25 will be described.
  • the right side of FIG. 25 shows a state where the first file 3002 (C: ⁇ test.txt) stored in the file system on the right side of FIG. 24 is copied to another directory.
  • the in-file trace information 3003 of the copy destination file 3004 C: ⁇ test ⁇ test.txt
  • OID operation identifier
  • the file storage identifier (FID) is the same as before copying.
  • the same information 3003 as the in-file trace information of the copy destination file 3004 and the operation contents are stored in association with each other.
  • the counter value included in the in-file trace information of the first file 3002 is It changes from “0” to “1”.
  • the record corresponding to the in-file trace information of the first file 3002 stored in the PC management DB is not changed before and after the copy operation.
  • the in-file trace information of the first file 3002 stored in the PC management DB is not changed at all. In other words, the same information as the in-file trace information after the file operation is stored in the PC management DB, and after that, even if the file corresponding to the in-file trace information is further operated, The content of the record corresponding to the file trace information does not change.
  • FIG. 26 shows a state where the file name of the file 3004 copied on the right side of FIG. 25 is changed from “text.txt” to “text2.txt”.
  • In-file trace information of the rename destination file 3006 (C: ⁇ test ⁇ text2.txt) is created based on the in-file trace information of the rename source file 3004 (C: ⁇ test ⁇ text.txt).
  • the created in-file trace information is stored in an alternative stream of the name change destination file 3006. Furthermore, the same information 3005 as the created in-file trace information is also stored in the PC management DB.
  • the operation identifier is set to “000”.
  • the operation identifier “00” and the count “0” of the name change source file 3004 are arranged into three digits.
  • the operation identifier “000” regarding the name change destination file 3006 is generated.
  • An initial value “0” is set in the count related to the name change destination file 3006.
  • in-file trace information relating to the first file 3002 (more precisely, information obtained by adding operation contents to the same information as the in-file trace information). The same applies to the following), and in-file trace information related to the copied file 3004 and in-file trace information related to the renamed file 3006 are stored in total.
  • the contents of each in-file trace information stored in the PC management DB are not changed regardless of subsequent file operations. This is because the transition (history) of file operations is detected and visualized based on each in-file trace information stored in the PC management DB.
  • FIG. 27 shows a state where the first file 3002 (C: ⁇ text.txt) has been moved to another directory (D: ⁇ ).
  • the in-file trace information related to the destination file 3009 (D: ⁇ text.txt) is created based on the in-file trace information of the source file 3002 (C: ⁇ text.txt). Stored. Similarly to the above, the same information as the in-file trace information is transmitted and stored in the PC management DB.
  • the operation identifier “01” related to the transfer destination file 3009 is created by arranging the operation identifier “0” and the count “1” of the transfer source file 3002 in two digits.
  • the initial value “0” is set as the count value. Note that the file storage identifier does not change through FIGS. 24-28.
  • FIG. 28 Since the left side of FIG. 28 is the same as the right side of FIG. 27, the state of the right side of FIG. 28 will be described.
  • the right side of FIG. 28 shows a state where the file 3009 moved on the right side of FIG. 27 is deleted from the file system.
  • the in-file trace information of the deleted file is created based on the in-file trace information of the file 3009 (D: ⁇ text.txt) to be deleted.
  • the same information 3010 as the created in-file trace information is transmitted and stored in the PC management DB.
  • the created in-file trace information is not stored in the alternative stream. This is because the file has been deleted and there is no alternative stream to be stored.
  • the operation identifier “010” related to the deleted file is created by arranging the operation identifier “01” and the count “0” of the deletion target file 3009 into three digits.
  • the initial value “0” is set in the count regarding the deleted file. Since the file has already been deleted, the count value will not increase.
  • FIG. 29 shows a storage example of the PC management DB.
  • the PC management DB has records 3101-3106 corresponding to each file operation.
  • Each record of the PC management DB includes, for example, a file storage identifier field 3110, an operation identifier field 3111, an operation type field 3112, an operation source path field 3113, and an operation destination path field 3114.
  • information such as the file operation date and time and the user who operated the file can be managed by the PC management DB.
  • the file storage identifier field 3110 and the operation identifier field 3111 are essential information for tracking and visualizing file operations.
  • the other fields are information indicating the contents of the file operation.
  • the user When the user (administrator) wishes to output a file operation history, the following processing is executed.
  • the user selects in-file trace information as a starting point.
  • the manager 112 in the management server 111 searches the PC management DB with the file storage identifier included in the in-file trace information selected by the user. As a result, only the record having the file storage identifier selected by the user is extracted. Furthermore, the manager 112 rearranges each record having the file storage identifier selected by the user based on the operation identifier.
  • the information obtained in this way indicates the history of file operations originating from the same file.
  • the in-file trace information in which the digits from the beginning of the operation identifier to the one before the last digit are common belongs to the operation of the same system.
  • In-file trace information in which the number of digits of the operation identifier (the number of characters of the operation identifier) is one more in the in-file trace information belonging to the file operation of the same system indicates the next operation.
  • FIG. 30 shows an example of in-file trace information stored in the alternative stream.
  • a file identifier, an operation identifier, and a count are stored in an ini file format.
  • UUID Universally Unique Identifier
  • the operation identifier has 32 digits
  • the range of characters that can be used for the operation identifier is 0-9, AZ, and az. The range is from 0 to 60.
  • FIG. 31 shows a sequence for monitoring file operations.
  • a file operation for example, file creation, movement, copying, renaming, or deletion
  • an application program such as Explorer (1201)
  • the file operation monitoring module 350 detects the file operation. To do.
  • file copy will be mainly described.
  • the file operation monitoring module 350 confirms the copy source and the copy destination (1202), and writes the acquisition source information in the alternative stream of the operated file as necessary (1203). Then, the file operation monitoring module 350 writes the in-file trace information in the alternative stream of the operated file (3301).
  • the file operation monitoring module 350 creates in-file trace information of the operation destination, transmits the in-file trace information of the operation destination to the manager 112 and stores it in the PC management DB, and further, if necessary, the in-file of the operation source Update trace information. Details of the operation of the in-file trace information will be described later.
  • FIG. 34 is a flowchart showing details of the processing 3301 for manipulating the in-file trace information shown in FIG.
  • the file operation monitoring module 350 determines whether or not the operation is a starting point of the file operation (3401).
  • the operation that is the starting point of the file operation means creation of a file. For example, an operation for downloading a file from a Web server or the like to the client PC 121 corresponds to an operation that is a starting point of the file.
  • the monitoring module 350 When it is determined that the file operation is the starting point, the monitoring module 350 newly creates in-file trace information (3402), and the newly created in-file trace information is added to the alternative stream of the newly created file. Write (3403). Further, the monitoring module 350 transmits the newly created in-file trace information to the manager 112 and stores it in the PC management DB (3404).
  • the monitoring module 350 attempts to acquire in-file trace information from the alternative stream of the file that is the operation source (3410). The monitoring module 350 determines whether in-file trace information has been acquired from the alternative stream of the operation source file (3411). If the in-file trace information cannot be acquired from the alternative stream of the operation source file, the monitoring module 350 newly creates in-file trace information for the operation source file (3412).
  • in-file trace information is not written in an alternative stream of a file existing before the file operation history management system according to the present embodiment is introduced into the computer system. Accordingly, in-file trace information is newly created in such a file and written in the alternative stream (3412, 3418).
  • the monitoring module 350 creates in-file trace information related to the operation destination file, and further updates the in-file trace information related to the operation source file when the update is necessary (3413). If in-file trace information can be acquired from the alternative stream of the operation source file in step 3411, the process proceeds to step 3413.
  • the monitoring module 350 executes the file operation desired by the user (3414), and determines whether or not the operation destination file exists (3415). If the operation destination file exists, the monitoring module 350 writes the in-file trace information regarding the operation destination file created in step 3413 to the alternative stream of the operation destination file (3416).
  • the monitoring module 350 determines whether or not the operation source file exists (3417). If the operation source file exists, the monitoring module 350 writes the in-file trace information created in step 3413 to the alternative stream of the operation source file if update is necessary (3418). For example, in the case of file copy, it is necessary to increase the count value in the in-file trace information regarding the operation source file (copy source file).
  • the monitoring module 350 displays the in-file trace information regarding the operation destination file in the manager 112. And store it in the PC management DB (3419).
  • the operation source file does not exist.
  • the operation source file exists only when the file is created or copied.
  • FIG. 33 shows details of step 3402 in FIG.
  • the monitoring module 350 generates a UUID (3501), and sets the UUID in the file storage identifier in the in-file trace information (3502).
  • the monitoring module 350 sets an initial value “0” for the operation identifier (3503), and further sets an initial value “0” for the count (3504).
  • FIG. 34 is a flowchart showing details of step 3413 in FIG.
  • the monitoring module 350 creates a copy of the in-file trace information related to the operation source file and uses it as a basis for the in-file trace information of the operation destination (3601).
  • the monitoring module 350 determines whether the number of digits of the operation identifier of the in-file trace information related to the operation destination file is smaller than 31 digits (3602). As described above, the operation identifier increases by one each time it is operated, and its upper limit is 32.
  • the monitoring module 350 determines whether or not the count value in the in-file trace information regarding the operation destination file is smaller than 60 (3603). As described above, the count increases by 1 each time it is copied, and its upper limit is 60. When the count value is less than 60, the monitoring module 350 adds one character converted from the count for the operation source file to the end of the operation identifier for the operation destination file (3604).
  • the operation identifier related to the operation destination file is a value in which the operation identifier related to the operation source file and the count related to the operation source file are arranged.
  • the monitoring module 350 sets an initial value “0” to the count relating to the operation destination file (3605), and if the count needs to be updated, the count value relating to the operation source file is incremented by one. Increase (3606). That is, when a file is copied, the count value of the operation source file is increased by one. In the case of other file operations, the count value of the operation source file does not change.
  • the monitoring module 350 determines whether the operation is an unauthorized operation (3607). As described in the first embodiment, for example, when a file in which an acquisition source identifier is set is output to an external server or a removable medium, it can be determined that the operation is unauthorized.
  • the monitoring module 350 sets “z” in the last digit (60th digit) of the operation identifier related to the operation destination file (3608). “0” is set in the count relating to the operation destination file (3609).
  • the monitoring module 350 sets “y” in the last digit (60th digit) of the operation identifier related to the operation destination file (3610). “0” is set in the count relating to the operation destination file (3611).
  • the monitoring module 350 determines whether an illegal file operation has been performed (3613). If it is not an illegal file operation, this process ends. When an illegal file operation is performed, the monitoring module 350 adds “0” to the last digit of the operation identifier related to the operation destination file to generate a 32-digit operation identifier (3614).
  • step 3607 and step 3613 The reason why it is determined in step 3607 and step 3613 whether or not the file operation is illegal is described. For example, when a file is written to the removable medium 125 or a file is uploaded to the Web server 131 outside the organization, the in-file trace information cannot be written to the alternative stream of the operation destination file. This is because the operation destination file exists outside the file system 204 of the client PC 121. Therefore, the operation destination file when operated illegally corresponds to the leaf at the end of the tree structure.
  • the number of digits of the operation identifier is 32 digits (32 characters), and the range of characters that can be used as the operation identifier is limited to 0-9, AZ, az is doing.
  • the value ( State) when the number of digits of the operation identifier reaches 32 characters (3614) and when the operation identifier ends with “z” (3608), the value ( State). In the case of an operation other than an illegal operation, transition is made to a state where the number of digits of the operation identifier in each previous state becomes 31 characters or a state where the character “y” is added to the operation identifier.
  • FIG. 36 shows a tree structure of a file operation history when the same file is copied many times.
  • the characters assigned to the operation identifiers related to the copy destination file increase to 0, 1, 2, and so on, and eventually reach the upper limit “y” (3802).
  • FIG. 37 shows a case where the operation destination file is further operated.
  • the number of digits of the operation identifier increases, and the number of digits of the operation identifier eventually reaches the upper limit of 31 digits (3901).
  • the operation identifier is not updated (3902, 3903).
  • “0” is set as the operation identifier for the taken-out file.
  • the operation identifier becomes 32 digits and becomes a leaf of the tree structure as in the case where “z” is added to the operation identifier. Therefore, if the tree structure is seen, it is immediately understood that the operation is illegal.
  • FIG. 38 shows a state in which the history of file operations is visualized as a tree structure using management information 4001-4008 stored in the PC management DB.
  • the user selects a file to be tracked from among the operations stored in the PC management DB.
  • the manager 112 of the management server 111 searches the PC management DB using the file storage identifier of the file selected by the user as a search key, and extracts a record having the selected file storage identifier. Furthermore, the manager 112 sorts the extracted records based on the operation identifier.
  • the rearranged result is a table 4010 shown on the upper side of FIG.
  • the result of Table 4010 is the depth-first search of the tree structure (Depth First In order to indicate the order of (Search), the tree structure 4020 can be easily drawn based on the result of the table 4010. Trace information obtained by removing the last character of the operation identifier becomes the parent trace information. For example, the parent operation of the operation whose operation identifier is “0010” (the parent operation is the operation immediately before) is an operation having the operation identifier “001”. In the tree display screen 4020 and the table 4010, 4001 and 4011, 4002 and 4012, 4003 and 4013, 4004 and 4014, 4005 and 4015, 4006 and 4016, 4007 and 4017, and 4008 and 4018 respectively correspond.
  • file operation history monitoring has been described focusing on file operations on the file system 204.
  • the present embodiment is not limited to file operations on the file system, but in cases such as uploading or downloading files using a web browser, sending / receiving files using e-mail, printing from application programs, etc. Is also applicable.
  • File operations are not limited to the above-described file creation, movement, copying, renaming, and deletion. For example, (1) File download using a web browser (2) Uploading files using a web browser (3) Receiving e-mail with attached files, (4) Saving attached files (5) Sending an email with an attached file, (6) Printing can be managed as a file operation.
  • the relationship between the operation source file and the operation destination file is as follows.
  • the operation source file is abbreviated as the operation source
  • the operation destination file is abbreviated as the operation destination.
  • (1) File download with Web browser (1A) Operation source ⁇ Download source URL (obtained in steps 403 and 502) (1B) Operation destination ⁇ save destination file path (obtained in steps 406 and 510) (2) File upload with Web browser (2A) Operation source ⁇ Upload file path (obtained at step 807) (2B) Operation destination ⁇ Upload destination URL (obtained in step 808)
  • Receiving an email with an attached file (3A) Operation source ⁇ Sender's email address (sender name in steps 604 and 704) (3B) Operation destination ⁇ Input source DB393 (4) Save attached file (4A) Operation source ⁇ Input source DB393 (4B) Operation destination ⁇ Save destination file path (obtained in steps 609 and 709) (5) Send email with attached file
  • FIG. 39 shows a configuration example of the input source DB 393.
  • the input source DB 393 can manage the file storage identifier, the operation identifier, and the count so that the operation source is the input source DB 393. Therefore, a file storage identifier field 4101, an operation identifier field 4102, and a count field 4103 are added to the input source DB 393.
  • the operation source is the input source DB 393, so that even when a file attached to an e-mail is copied to the file system 204 multiple times, the original operation (reception of an e-mail with an attached file) can be identified. Because. (4) Storage of attached file In step 3401, “No” is determined. In step 3410, in-file trace information is acquired from the input source DB 393 instead of acquiring in-file trace information from the alternative stream of the operation source. Similarly, in step 3418, the in-file trace information is stored in the input source DB 393. (5) Transmission of mail with attached file In step 3401, “No” is determined. In step 3415, it is determined “No” because the operation destination is the mail address (external). (6) Printing In step 3401, “No” is determined. In step 3415, it is determined “No” because the operation destination is a paper medium (external).
  • FIG. 40 shows a table 4210 extracted from the PC management DB according to the conditions selected by the user, and a file operation history tree structure 4220 drawn based on the table 4210.
  • the history of file operations can be efficiently managed. Furthermore, by using the file storage identifier and the operation identifier, the file operation history can be easily displayed in a tree structure.
  • DB For a DB that does not have a file storage identifier or operation identifier, after reading the operation source file from the DB, search the operation source file field in the operation source file, and use the searched file name to search the operation source file field. It is necessary to repeat the operation such as searching again and again. Accordingly, the number of accesses to the DB is greatly increased, and it takes time to create a table from which an operation history is extracted and to display a tree structure.
  • the operation history of the file selected by the user can be easily extracted and displayed in a tree structure simply by reading the file storage identifier and the operation identifier from the PC management DB. Therefore, usability is improved.
  • the file storage identifier, the operation identifier, and the count are written in the alternative stream of the file (further, as described in the first embodiment, the acquisition source identifier may be written in the alternative stream). Therefore, even if the PC management DB is temporarily stopped or a part of the record is damaged, the file operation history is managed by reading the in-file trace information stored in the alternate stream of the file. can do.
  • information for managing the history of file operations may be stored and managed in the DB in the client PC, instead of being stored in the alternate stream of the file.
  • the operation history of files input to and output from the client PC can be monitored using a DB configured as shown in FIG.
  • an attached data area such as a resource fork may be used.
  • the attached data area is a data area attached to a file, and is an area to be operated together with the file data when the file is operated.
  • data can be read and written by using a function different from the read function or write function for file data, or by specifying an unusual argument to the read function or write function. .
  • the URL or mail address and the full path on the file system 204 are acquired by acquiring a user operation on a Web browser or an input character string to a dialog.
  • another method is used to detect the correspondence between the file path information (full path) and the URL or mail address.
  • FIG. 41 shows the configuration of the client PC 121.
  • the disk 209 stores a file system 204, a system policy 391, a security policy 392, a browser input DB 4901, a browser output DB 4902, a mail input DB 4903, and a mail output DB 4904.
  • FIG. 42 shows the configuration of the agent program 122.
  • a process monitoring module 310 a printer monitoring module 320, a file I / O monitoring module 370, an HTTP communication monitoring module 380, and a TCP communication monitoring module 360 are provided.
  • the file I / O monitoring module 370 writes a source information (source identifier) in a file I / O detection function 371 that detects file input / output generated by the Web browser 305 or various application programs, and an alternative stream of the file. Acquisition source information adding function 372.
  • HTTP communication monitoring module 380 includes a socket reception detection function 381 that detects file transmission / reception, a protocol analysis function 382 that analyzes data transmitted / received via socket 308, and a function that assigns and inspects registration and source information. 383.
  • the function 383 for performing registration, notification, and the like adds acquisition source information to the file and registers it in the browser input DB 4901.
  • the TCP communication monitoring module 360 and the HTTP communication monitoring module 380 monitor communication on the communication network.
  • the TCP communication monitoring module 360 monitors transmission / reception of mail (POP3 / IMAP / SMTP).
  • the HTTP communication monitoring module 380 monitors HTTP communication.
  • the file I / O monitoring module 370 monitors file reading and writing using a Web browser or a mailer.
  • DB4901-4904 using hash values of the file data as keys is provided. .
  • the TCP communication monitoring module 360 or the HTTP communication monitoring module 380 can acquire the download source information (URL or email address) and download data.
  • the download source information and the hash value of the downloaded data are stored in the input DB (see FIGS. 48 and 50).
  • FIG. 48 shows a configuration example of the browser input DB 4901.
  • the browser input DB 4901 manages files downloaded via a web browser.
  • the browser input DB 4901 includes, for example, an acquisition source URL field 4901A, a hash value field 4901B, a file storage identifier field 4901C, an operation identifier field 4901D, and a count field 4901E.
  • the URL from which the file is downloaded is stored in the source URL field 4901A.
  • the hash value 4901B stores a hash value calculated from the downloaded file data.
  • the file storage identifier field 4901C stores a file storage identifier assigned to the downloaded file.
  • the operation identifier field 4901D stores an operation identifier set in the downloaded file.
  • the count field 4901E stores a count relating to the downloaded file. The same applies to hash values, file storage identifiers, operation identifiers, and counts for other DBs described later.
  • FIG. 50 shows an example of the DB 4903 that manages files (files attached to e-mails) acquired via the mailer.
  • the mail input DB 4903 includes, for example, a file name field 4903A, a sender name field 4903B, a hash value field 4903C, a file storage identifier field 4903D, an operation identifier field 4903E, and a count field 4903F.
  • the file name field 4903A the name of the file attached to the e-mail is stored.
  • the sender name field 4903B stores the sender name of the e-mail attached with the file.
  • the hash value, file storage identifier, operation identifier, and count are the same as those in FIG.
  • the downloaded file data is written on the file system of the client PC.
  • the file I / O monitoring module 370 detects writing of file data to the file system 204.
  • the file I / O monitoring module 370 obtains the hash value of the file data stored by the browser or mailer, and searches for a record having the same hash value in the input DBs 4901 and 4903 (FIGS. 48 and 50). When a record having the same hash value exists, the record indicates a downloaded file. Therefore, corresponding input source information and in-file trace information are added to the file specified by the hash value.
  • the user can send the file to the outside of the client PC using a Web browser or electronic mail.
  • the browser or mailer reads the file data to be uploaded.
  • the file I / O monitoring module 370 detects reading of the file data.
  • the file I / O monitoring module 370 obtains the path and hash value of the file read by the browser or mailer and stores them in the output DBs 4902 and 4904 (FIGS. 49 and 51).
  • FIG. 49 shows a DB 4902 that manages files output to the outside of the client PC 121 using a browser.
  • the browser output DB 4902 includes, for example, an upload file field 4902A, a hash value 4902B, a transmission source field 4902C, a server field 4902D, a URL field 4902E, a file storage identifier field 4902F, an operation identifier field 4902G, and a count field 4902H.
  • the upload file field 4902A path information indicating the storage location of the uploaded file is stored.
  • the transmission source field 4902C stores the name of the user who uploaded the file.
  • the server field 4902D stores the upload destination server name.
  • the URL field 4902E stores the upload destination URL.
  • the browser or mailer When the browser or mailer reads the file data, it uploads the file data.
  • the TCP communication monitoring module 360 or the HTTP communication monitoring module 380 detects file upload.
  • the TCP communication monitoring module 360 or the HTTP communication monitoring module 380 acquires the data of the uploaded file and obtains its hash value.
  • the TCP communication monitoring module 360 or the HTTP communication monitoring module 380 searches the output DBs 4902 and 4904 for records having the same hash value as the obtained hash value. If records with the same hash value exist, it can be determined that the user uploaded the file. When it is determined that the file has been uploaded, as described in the first embodiment, whether or not the alert condition is met, transmission of the alert, operation of in-file trace information, and the like are performed.
  • FIG. 43 shows a sequence for downloading a file using a browser.
  • the HTTP communication monitoring module detects the header of HTTP communication and analyzes the header (5102). If the result of the analysis is a reception operation, step 5103 and subsequent steps are executed. If it is a transmission operation, step 5212 and subsequent steps in FIG. 44 are executed.
  • the HTTP communication monitoring module acquires the acquisition source URL and the acquisition data (download file) from the analysis result in step 5102 (5103).
  • the HTTP communication monitoring module calculates the hash value of the obtained data acquired in step 5103 (5104).
  • the HTTP communication monitoring module operates the in-file trace information shown in FIG. 32 (5105). Here, since the file is downloaded by the browser, in-file trace information is newly created.
  • the HTTP communication monitoring module stores the source URL, the hash value of the acquired data, and the in-file trace information in the browser input DB 4901 (5106).
  • the browser When the file download is started, the browser receives the download data from the socket 308 and writes the download data to the file system 204 (5111).
  • the file I / O monitoring module detects the operation of step 5111 using a method such as an API (Application Programming Interface) hook (5112).
  • the file I / O monitoring module obtains a hash value of data written by the browser to the file system 204 (5113).
  • the file I / O monitoring module acquires a file write destination path by the browser (5114).
  • the file I / O monitoring module searches the browser input DB 4901 using the hash value obtained in step 5113 as a search key. When a record having the same hash value is found, the file managed by the record is a file downloaded by the user. Therefore, the file I / O monitoring module acquires file attributes (source URL, file operation trace information) from the browser input DB 4901 and executes step 5116 and subsequent steps.
  • file attributes source URL, file operation trace information
  • the file I / O monitoring module writes the source information (1311 in FIG. 13) to the alternative stream of the file found based on the hash value (5116). Further, the file I / O monitoring module writes in-file trace information (3201 in FIG. 30) in the alternative stream of the file (5117).
  • FIG. 44 is a sequence showing file upload processing using a browser.
  • the browser reads the file to be uploaded (5202).
  • the file I / O monitoring module detects the operation of step 5202 using a method such as an API hook (5203).
  • the file I / O monitoring module obtains the hash value of the file read by the browser (5204).
  • the file I / O monitoring module acquires the source information from the alternative stream of the file (5205).
  • the file I / O monitoring module acquires in-file trace information from the alternative stream of the file (5206).
  • the file I / O monitoring module stores the file path, file hash value, source information, and in-file trace information in the browser output DB 4902 (FIG. 49).
  • the browser When the browser completes reading of the upload file, the browser uploads the file via the socket 308. This transmission operation is detected by the HTTP communication monitoring module (5211).
  • the HTTP communication monitoring module analyzes the HTTP header (5211), and if it is a transmission operation, executes step 5212 and subsequent steps. If the operation is a reception operation, the processing after 5103 in FIG. 43 is executed.
  • the HTTP communication monitoring module acquires the upload destination URL and the upload data from the header analysis result in step 5211 (5212).
  • the HTTP communication monitoring module calculates the hash value of the upload data acquired in step 5212 (5213).
  • the HTTP communication monitoring module searches the browser output DB 4902 based on the hash value obtained in step 5213, and acquires a record having the same hash value as the hash value of the uploaded file.
  • the file managed by the record is a file uploaded by the user. Accordingly, the HTTP communication monitoring module acquires the file attributes (file path, source information, file operation trace information (FID, OID, count)) from the record (5214), and executes Step 5215 and subsequent steps. If no record with the same hash value is found, the process ends because the communication is by a program other than the browser to be monitored.
  • the HTTP communication monitoring module operates the in-file trace information for the file detected based on the hash value (5215). Further, the HTTP communication monitoring module checks whether the file upload by the browser matches the alert condition, and transmits an alert if necessary (5216).
  • FIG. 45 is a sequence related to reception of a file using a mailer and storage of the received file.
  • the TCP communication monitoring module detects the header of TCP communication and analyzes the header (5302).
  • Step 5303 If the file is attached to the received mail as a result of the analysis, execute Step 5303 and subsequent steps. If a file is attached to the mail to be transmitted, 5412 and subsequent steps in FIG. 44 are executed. In the case of mail transmission / reception with no attached file or communication other than mail transmission / reception, this processing is terminated.
  • the TCP communication monitoring module obtains the sender name of the mail, the file name of the attached file, and the data of the attached file from the analysis result in step 5302 (5303). Subsequently, the TCP communication monitoring module calculates the hash value of the attached file data acquired in step 5303 (5304).
  • the TCP communication monitoring module operates the in-file trace information shown in FIG. 32 (5305). Since this is a case where an email with an attached file is received, new in-file trace information is created.
  • the TCP communication monitoring module stores the attached file name, sender name, hash value of attached file data, and in-file trace information in the mail input DB 4903 (FIG. 50) (5306).
  • the mailer When the user saves the file attached to the mail (5310), the mailer writes the attached file to the file system 204 (5311).
  • the file I / O monitoring module detects the operation of step 5311 using a method such as an API hook (5312).
  • the file I / O monitoring module obtains a hash value of the file data written by the mailer (5313). Further, the file I / O monitoring module acquires the path where the mailer has written the file (5314).
  • the file I / O monitoring module searches the mail input DB 4903 (FIG. 50) based on the hash value obtained in step 5313.
  • the file corresponding to the record is a file attached to the mail. Therefore, the file I / O monitoring module acquires file attributes (attached file name, sender name, file operation trace information) from the record (5315) and executes step 5316 and subsequent steps.
  • step 5311 is not the file write that occurred in the download operation of the attached file (5310), so this process ends.
  • the file I / O monitoring module operates in-file trace information (5316).
  • the file operation trace information is written in the alternative stream of the saved file (the foul attached to the mail and stored in the file system 204) (5316). Further, the file I / O monitoring module gives the source information (1311 in FIG. 13) to the alternative stream of the saved file.
  • FIG. 46 shows a sequence in the case of sending a file with a file attached.
  • the mailer reads the file attached to the email from the file system 204 (5402).
  • the file I / O monitoring module detects the file read in step 5402 by a method such as an API hook (5403).
  • the file I / O monitoring module obtains the hash value of the file read by the mailer (5404).
  • the file I / O monitoring module acquires the acquisition source information from the alternative stream of the file (5405).
  • the file I / O monitoring module acquires in-file trace information from the alternative stream of the file (5406).
  • the file I / O monitoring module stores the file path, file hash value, acquisition source information, and in-file trace information in the mail output DB 4904 (FIG. 51) (5407).
  • the mailer When the user sends an email with a file attached (5410), the mailer sends an email with the file attached via the socket 308.
  • the TCP communication monitoring module detects the mail transmission and analyzes the TCP header (5411). If a mail with a file attached is transmitted, step 5412 and subsequent steps are executed. If a mail with a file attached is received, 5303 and subsequent steps in FIG. 45 are executed. In the case of transmission or reception of mail without a file attached, or in the case of communication other than mail transmission / reception, this processing is terminated.
  • the TCP communication monitoring module obtains the destination email address and the file data attached to the email from the header analysis result in step 5411 (5412).
  • the TCP communication monitoring module calculates the hash value of the file data acquired in step 5412 (5413).
  • the TCP communication monitoring module searches the mail output DB 4904 and the mail input DB 4903 based on the hash value obtained in Step 5413, and acquires the file attribute (5414). The reason for searching the mail output DB 4904 and the mail input DB 4903 will be described later.
  • the TCP communication monitoring module operates the in-file trace information for the file detected based on the hash value (5415), checks the alert condition, and transmits an alert if necessary (5416).
  • FIG. 47 shows a sequence for transferring a mail with a file attached.
  • the processing for transferring a mail with a file attached is the same as the processing from step 5410 to step 5416 shown in FIG. That is, steps 5510-5516 in FIG. 47 are the same as steps 5410-5416 in FIG.
  • the TCP communication monitoring module only monitors communication, and determines whether the monitored communication is communication corresponding to FIG. 46 (mail transmission) or communication corresponding to FIG. 47 (mail transfer). Can not. Therefore, in this embodiment, both the mail output DB 4904 and the mail input DB 4903 are searched regardless of whether the mail is transmitted or forwarded.
  • communication between the client PC and the network is monitored, and input / output to the file system is monitored. Then, the file is identified by comparing the hash value of the file detected by communication with the hash value of the file managed by the file system. Associate source information and in-file trace information with the specified file.
  • the file can be specified relatively easily compared to the configuration in which the file is specified based on the user operation using the browser or based on the character string input to the dialog.
  • an email address or URL can be associated with a file.
  • the type of browser used by the user may change, or the browser may be upgraded.
  • the configuration of the dialog changes due to version upgrade of the application program, or a completely new application program is installed in the client PC 121.
  • the communication monitoring result and the monitoring result of input / output to the system are associated with each other by a common hash value. Therefore, the influence of the environmental change as described above can be reduced, and the system can be maintained and operated relatively easily.
  • This embodiment can be combined with the first embodiment or the second embodiment.
  • this invention is not limited to the Example mentioned above.
  • a person skilled in the art can make various additions and changes within the scope of the present invention.
  • the second embodiment can be combined with the first embodiment or can be configured independently of the first embodiment. That is, the history of file operations can be managed and visualized in a tree structure within one client PC or within a group including a plurality of client PCs.
  • 111 ... Management server, 114 ... Mail server, 115 ... File server, 116 ... Internal web server, 121 ... Client PC, 122 ... Agent program, 123 ... Network printer 123, 204 ... Local file system, 310 ... Process monitoring module, 320 ... Printer monitoring module, 330 ... Browser monitoring module, 340 ... Dialog operation monitoring module, 350 ... File operation monitoring module, 360 ... TCP communication monitoring module, 370 ... File I / O monitoring module, 380 ... HTTP communication monitoring module, 393 ... source DB, 1311 ... identifier indicating source, 3201 ... in-file trace information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

ファイル操作の履歴を効率的にツリー構造として表示すること。 クライアント端末のファイルシステムに記憶される各ファイルには、その代替データストリームに、追加のメタ情報として、ファイル格納識別子と、操作識別子と、カウントとが記憶される。操作識別子は、操作回数(操作の世代)を管理する。カウントは、コピー回数を管理する。そのメタ情報は管理装置にも送られ、ファイル操作の履歴をツリー構造で表示するために使用される。

Description

計算機システムの管理方法及びクライアントコンピュータ
 本発明は、計算機システムの管理方法及びクライアントコンピュータに関する。
 悪意のある操作、又は、疑わしい操作を検知する操作検知システムとして、特許文献1がある。特許文献1で示される技術では、あらかじめ管理者(ユーザ)が悪意ある不正操作パターンを作成し、ログ分析サーバのデータベースに登録した上で、予め記録しておいたユーザの操作ログの内容のマッチング度により危険性を判断する。
特開2009-20812号公報
 特許文献1記載の技術の操作パターンではクライアントPC自体に格納されたファイルの情報漏えいの検知が可能であるが、クライアントPC外部の複数のサーバ計算機にアクセスを行った場合に、クライアントPC管理者が意図した漏えい検知を容易に行うことが出来ない。また、上記の従来技術では、ファイル操作の履歴を簡単に表示することもできない。
 前記目的を達成するために、本発明は、ファイルの操作履歴に関する情報を、追加のメタ情報として用いる。追加のメタ情報は、ファイル内の所定の記憶領域またはファイル外の他の領域に記憶される。そのメタ情報は、ファイルがクライアントコンピュータのファイルシステムに格納された場合に付与されるファイル格納識別情報と、操作の回数を示す操作世代識別情報と、コピー回数を示すコピー回数情報を含むことができる。ファイルが操作されると、操作先のファイルに関してメタ情報が作成され、対応付けられる。メタ情報は管理装置にも送られて記憶される。管理装置の保持するメタ情報に基づいて、ファイルの操作履歴を検出して表示させることができる。
 さらに、本発明では、不正なファイル操作を検出するための不正操作検知システムを備える。不正操作検知システムは、監視装置と管理端末とを備える。監視装置は、クライアントコンピュータのマイクロプロセッサを監視対象として、監視対象に接続された出力装置の画面上の情報に対する操作を監視する。管理端末は、監視装置を管理対象として、監視装置の監視結果を管理する。
 監視装置は、監視対象に情報を入力するための操作に応答して、監視対象に入力される入力情報の入手元を識別するとともに、入力情報に、当該入力情報の入手元を示す識別子を付与し、監視対象から情報を出力するための操作に応答して、監視対象から出力される出力情報の出力先を識別するとともに、出力情報の入手元を示す識別子を検索し、識別された出力情報の出力先と検索された出力情報の入手元の組み合わせが不正操作の条件に適合するか否かを判定し、この判定結果に従ってアラートを生成する。
本発明の計算機システムの一実施形態を示すシステム構成図である。 本発明におけるクライアントPCの構成の一例を示す図である。 クライアントPC上で動作するエージェントプログラムの構成の一例を示す図である。 Webブラウザでファイルをインポートする際に、ユーザの操作と、ダイアログ操作監視モジュールと、ブラウザ監視モジュールとの間で実行されるシーケンスの一例を示す図である。 Webブラウザでファイルをインポートする際に、ユーザの操作と、ダイアログ操作監視モジュールと、ブラウザ監視モジュールと、ファイル操作監視モジュールの間で実行されるシーケンスの一例で示す図である。 メーラでファイルをインポートする際に、ユーザの操作と、ダイアログ操作監視モジュールと、TCP通信監視モジュールとの間で実行されるシーケンスの一例を示す図である。 メーラでドラッグ&ドロップを用いてファイルをインポートする際に、ユーザの操作と、ファイル操作監視モジュールと、TCP通信監視モジュールとの間で実行されるシーケンスの一例を示す図である。 Webブラウザでファイルをエクスポートする際に、ユーザの操作と、ダイアログ操作監視モジュールと、ブラウザ監視モジュールとの間で実行されるシーケンスの一例を示す図である。 メーラでファイルをエクスポートする際に、ユーザの操作と、ダイアログ操作監視モジュールと、TCP通信監視モジュールとの間で実行されるシーケンスの一例を示す図である。 メーラでドラッグ&ドロップを用いてファイルをエクスポートする際に、ユーザの操作と、ファイル操作監視モジュールと、TCP通信監視モジュールとの間で実行されるシーケンスの一例を示す図である。 ファイルを印刷する際に、ユーザの操作と、ダイアログ操作監視モジュールで実行されるシーケンスの一例を示す図である。 ファイルサーバからファイルをインポートする際と、リムーバブルメディアにファイルをエクスポートする際に、ユーザの操作と、ファイル操作監視モジュールで実行されるシーケンスの一例を示す図である。 エージェント内で使用される入手元DBと、各ファイルに付与される入手元情報のフォーマットの一例を示す図である。 エージェント内のモジュールである、ブラウザ監視モジュールのフローチャートの一例を示す図である。 エージェント内のモジュールである、ダイアログ操作監視モジュールのフローチャートの全体像の一例を示す図である。 エージェント内のモジュールである、ダイアログ操作監視モジュールのメーラによるダウンロード・アップロードスレット部分のフローチャートの一例を示す図である。 エージェント内のモジュールである、ダイアログ操作監視モジュールのブラウザによるダウンロード・アップロードスレット部分のフローチャートの一例を示す図である。 エージェント内のモジュールである、ダイアログ操作監視モジュールの印刷チェックスレッド部分のフローチャートの一例を示す図である。 エージェント内のモジュールである、ファイル操作監視モジュールのフローチャートの一例を示す図である。 エージェント内のモジュールである、TCP通信監視モジュールのフローチャートの一例を示す図である。 本発明の動作に関連する、Webブラウザの画面の一例を示す図である。 本発明における管理サーバの構成の一例を示す図である。 本発明の第2実施例に係り、ファイル操作に伴ってメタ情報(インファイルトレース情報)が生成される様子を示す。 初期状態、及び、ファイルコピーまたはファイルダウンロード等によりインファイルトレース情報が作成された状態を示す。 図24右側に示す状態から、コピー操作が行われた状態を示す。 図25右側に示す状態から、ファイル名が変更された状態を示す。 図26右側に示す状態から、ファイルが移動された状態を示す。 図27右側に示す状態から、ファイルが削除された状態を示す。 管理サーバに記憶された情報に基づいて、ファイル操作をトレースする一例を示す。 インファイルトレース情報の一例を示す。 ユーザによるファイル操作を監視するシーケンスを示す。 インファイルトレース情報を作成または更新する処理を示すフローチャートである。 インファイルトレース情報を作成する処理のフローチャートである。 操作先ファイルのインファイルトレース情報を作成する処理と、操作元ファイルのインファイルトレース情報を更新する処理と、を示すフローチャートである。 カウント値を文字コードに変換するためのテーブルを示す。 コピー回数が所定のコピー回数に達した場合に、操作識別子の最終桁に文字コードが付加される様子を示す。 操作回数(操作世代数)が所定の操作回数に達した後、ファイルが不正に操作された場合は、操作識別子の桁数を上限値にする様子を示す。 管理サーバに記憶された情報(インファイルトレース情報と同一の情報)に基づいて、ファイル操作の履歴をツリー構造で表示させる様子を示す。 電子メールに添付されたファイル等の操作履歴を追跡するために使用されるデータベースの一部を示す。 電子メールに添付されたファイルの操作履歴をツリー構造で表示させる様子を示す。 第3実施例に係り、クライアントコンピュータの構成例を示す。 エージェントプログラムの構成を示す。 ウェブブラウザを用いてファイルをダウンロードする場合の監視シーケンスを示す。 ウェブブラウザを用いてファイルをアップロードする場合の監視シーケンスを示す。 電子メールを受信する場合の監視シーケンスを示す。 電子メールを送信する場合の監視シーケンスを示す。 電子メールを転送する場合の監視シーケンスを示す。 ウェブブラウザを介してダウンロードされたファイルの操作履歴を監視するために使用されるデータベースの一部を示す。 ウェブブラウザを介してアップロードされたファイルの操作履歴を監視するために使用されるデータベースの一部を示す。 受信された電子メールに添付されたファイルの操作履歴を監視するために使用されるデータベースの一部を示す。 送信された電子メールに添付されたファイルの操作履歴を監視するために使用されるデータベースの一部を示す。 ファイルの操作の履歴を管理するための情報を格納する変形例を示す。
 以下、本発明の実施形態を説明する。まず最初に、不正なファイル操作を検知するための方法を説明し、次に、ファイル操作の履歴を管理する方法を説明する。さらに、ファイルのパスを取得する方法を説明する。
 本実施例は、「クライアントコンピュータ」としてのクライアントPC(Personal Computer)で稼動するアプリケーションプログラムに対する操作内容を監視し、クライアントPCに入力される入力情報の入手元を識別するとともに、入力情報に、当該入力情報の入手元を示す識別子を付与する第一の手段と、クライアントPCから出力される出力情報の出力先を識別するとともに、出力情報に付与された識別子を検査し、出力情報の入手元と出力先の条件に応じてアラートを生成する第二の手段を有するものである。
 以下、本発明の一実施例を図面に基づいて説明する。図1は、本発明の不正操作検知システムの一実施形態を示すシステム構成図である。本発明の不正操作検知システムは、情報センタ101内のLAN(LOCAL Area Network)117と拠点102内のネットワーク124が広域ネットワーク103で接続され、前記情報センタ101は、さらに広域ネットワーク104を介してインターネットに接続されているものとする。不正操作検知システムは、情報センタ101内に設置された管理サーバ111と、拠点102内に設置されたクライアントPC121により構成される。
 管理サーバ111は、情報センタ101内と拠点102内を管理領域とし、この管理領域内に配置された機器、例えば、メールサーバ114、ファイルサーバ115、組織内Webサーバ116、クライアントPC121、ネットワークプリンタ123などを管理対象として、これら管理対象を管理する。この管理サーバ111では、不正操作検知システムの全体を統括するマネージャ112と、前記マネージャが複数のクライアントPCを管理するために使用するPC管理DB(DataBase)を格納するディスク113が稼動する。管理サーバ111は、「管理端末」または/及び「管理装置」に該当する。
 各クライアントPC121は、各種アプリケーションプログラムが搭載されたマイクロプロセッサで構成されている。各クライアントPC121では、各クライアントPC121を監視対象とし、この監視対象に接続された出力装置の画面上の情報に対する操作を監視する監視装置としてのエージェント122が稼動する。クライアントPC121は、例えば、パーソナルコンピュータ、携帯情報端末、携帯電話等のようなコンピュータとして構成される。
 クライアントPC121を使用するユーザは、電子メール、Webサーバ、ファイルサーバ等を用いて業務を遂行する。このため、情報センタ101には、メールサーバ114と、ファイルサーバ115と、組織内Webサーバ116が設置されており、LAN117に接続されている。またインターネットには、クライアントPC121からアクセス可能な組織外Webサーバ131が接続されている。
 また、拠点102内のネットワーク124には、印刷に使用するネットワークプリンタ123が接続されている。なお、組織外Webサーバ131と、クライアントPC121に接続される記憶媒体のうちフラッシュメモリなどのリームバブルメディア125は、管理サーバ111の管理対象から外れた機器であって、検査対象として処理される。
 図22は、本発明における管理サーバ111の構成の一例を示すブロック構成図である。管理サーバ111は、CPU(Central Processing Unit)2201、バス2202、メモリ2203、ディスク113、113内にあるPC管理DB2204、ネットワークI/F2205、デバイスI/F2206、入力デバイス2208、表示デバイス2209、から構成されている。デバイスI/F2206は、例えば、USB(Universal Serial Bus)インタフェース等で構成される。メモリ2203上にはOS(Operating System)2207がロードされており、マネージャプログラム112が動作している。
 図2は、本発明におけるクライアントPC121の構成の一例を示すブロック構成図である。クライアントPC121は、CPU(Central Processing Unit)201、バス202、メモリ203、ローカルファイルシステム204、ネットワークI/F205、デバイスI/F206、ディスク209、入力デバイス210、表示デバイス211、を備えている。デバイスI/F 206は、例えば、USB(Universal Serial Bus)インタフェース等で構成される。メモリ203上にはOS(Operating System)207がロードされている。OS207の上で、不正操作検知システムの構成要素であるエージェント122のプログラムと、ファイルエクスプローラ、Webブラウザ(ブラウザと略記する場合がある)、メーラ、ワードプロセッサまたは表計算ソフトといった複数のアプリケーションプログラム(アプリケーションと略記する場合がある)208がメモリ203に格納されて動作している。
 ここで、クライアントPC121を使用するユーザは、アプリケーションプログラム208のいずれかを用いて、メールサーバ114に到着した自分宛のメールに添付されたファイル、または、ファイルサーバ115内に格納されたファイル、または、組織内Webサーバ116に登録されたファイルを、ローカルファイルとして、クライアントPC121のファイルシステムフォーマットされたディスク209内のローカルファイルシステム204に保存する。
 ローカルファイルシステム204に保存されたファイル209は、アプリケーションプログラム208のいずれかを用いて、クライアントPC121の外部にエクスポートされることがある。例えば、ファイルエクスプローラを用いて、デバイスI/F206に接続されたリムーバブルメディアにコピーされたり、または、ワードプロセッサあるいは表計算ソフトの印刷機能を用いて、ネットワークプリンタ123で印刷されたりする。
 また、メーラで作成したメール本文にファイルを添付して、組織内および組織外の相手にファイルを送信されたり、組織内および組織外にあるWebサーバにファイルをアップロードされたりする。
 このとき用いるWebブラウザ画面を図21に示す。図21は、ユーザがクライアントPC121でアプリケーションを操作して、ファイルをインポートする際の画面の一例を示す図である。
 Webブラウザ画面(クライアントPC121に接続される出力装置の画面)2101上には、いわゆるリンクと呼ばれるエリアが存在する。そのリンクをポインティングデバイス(クライアントPC121に接続されるマウス等の入力装置)を用いてクリックすると、画面遷移等が引き起こされる。リンク文字列2102上にマウスカーソルを置き、左ボタンをクリックした場合、次の画面(ページとも言う)に遷移するか、もしくは、クリックしたリンク先にある対象(ファイル)をダウンロードするためのダウンロードダイアログ2111を表示する処理が実行される。
 また、リンク文字列2102上にマウスカーソルを置き、右ボタンをクリックした場合、いわゆるコンテキストメニューと呼ばれるポップアップウィンドウが表示される。ここで表示されたコンテキストメニュー2103には、「対象をファイルに保存(A)…」という項目があり、この項目を左クリックすることにより、対象をダウンロードするためのダウンロードダイアログ2111を表示する処理が実行される。
 ダウンロードダイアログ2111には、ダウンロードしたファイルを保存する場所を示すフィールド2112と、保存先フォルダの選択肢を表示するフィールド2113と、保存するファイル名を示す2114がある。保存するファイル名は書き換えることが可能である。ユーザは、フィールド2112および2113を操作してファイルを保存するフォルダを選択し、必要に応じてフィールド2114で保存ファイル名を変更し、保存ボタン2115をクリックすることにより、Webブラウザを用いてファイルをダウンロードし、任意のフォルダにファイルを保存することができる。
 図3は、クライアントPC121上で稼動するエージェント122のモジュール構成の一例を示す図である。エージェント122は、マネージャ112との通信を担当するマネージャ通信機能モジュール301と、クライアントPC121でのユーザの操作を監視する各種監視モジュールを統括する監視モジュール制御モジュール302を持つ。
 エージェント122は、プロセス監視モジュール310と、プリンタ監視モジュール320と、ブラウザ監視モジュール330と、ダイアログ操作監視モジュール340と、ファイル操作監視モジュール350と、TCP通信監視モジュール360を有する。
 プロセス監視モジュール310は、クライアントPC121上で稼動するアプリケーションプログラム303の稼働状況を監視する。プリンタ監視モジュール320は、ネットワークプリンタ123を含むプリンタ304への出力操作を監視する。ブラウザ監視モジュール330は、Webブラウザ305によるユーザの操作を監視する。ダイアログ操作監視モジュール340は、クライアントPC121の画面上に表示され、ユーザがダウンロードまたはアップロードの際にファイルを選択するために使用する各種ダイアログ306を監視する。ファイル操作監視モジュール350は、クライアントPC121の画面上で、ユーザがマウス等のポインティングデバイスを用いて、前記画面上に表示された各種アプリケーション307に対する操作(例えば、ボタンのクリックやアプリケーションウィンドウ内に表示されたオブジェクトのドラッグ&ドロップなど)を監視する。TCP通信監視モジュール360は、例えば、メーラなど、ネットワークを介してデータを送受信するアプリケーションが、ユーザの操作によりTCP/IP(Transmission Control Protocol/ Internet Protocol)のソケット308等を用いてデータストリームを送信もしくは受信している状況を監視する。
 また、エージェント122は、モジュールの動作を制御するための設定ファイルであるシステムポリシ391と、特にセキュリティに関連する制御を行うための設定ファイルであるセキュリティポリシ392を持つとともに、先ほど説明した監視モジュール群がユーザ操作に関連する情報を構成する上で必要となる情報を格納する入手元DB393を備えている。入手元DB393の内容や役割については後述する。
 プロセス監視モジュール310は、クライアントPC121上でプロセス303の起動が要求されたことを検知する起動検知機能311と、起動されるプロセス303がセキュリティポリシ392に抵触するものである場合に、起動を抑止する抑止機能312と、ユーザに起動を抑止したことを通知するユーザ通知機能313を実現するものである。
 プリンタ監視モジュール320は、クライアントPC121上でプリンタ304を用いた印刷が要求されたことを検知する印刷検知機能321と、印刷されるデータがセキュリティポリシ392に抵触するものである場合に、印刷を抑止する抑止機能322と、ユーザに起動を抑止したことを通知するユーザ通知機能323を実現するものである。
 ブラウザ監視モジュール330は、クライアントPC121上でブラウザ305を用いてWebサーバにアクセスしたことを検知するアクセス検知機能331と、アクセスしたWebサーバのURL(Uniform Resource Name)、受信したhtml(Hypertext Markup Language)データ等を一時的に保持する検知内容保持機能332を実現するものである。
 ダイアログ操作監視モジュール340は、ユーザがクライアントPC121上のアプリケーションプログラム208を操作することにより、ファイル選択用ダイアログ、もしくは印刷用ダイアログが表示されたことを検知するダイアログ検知機能341と、前記ダイアログを用いて操作されたファイルに対し、そのファイルの入手元に関する情報の付与、および、付与された入手元に関する情報の検査を実行する入手元情報付与・検査機能342を実現するものである。
 ここで、ファイル選択用ダイアログを表示する操作とは、例えば、Webブラウザを用いてファイルをダウンロードもしくはアップロードする操作や、メーラを用いて受信メールから添付ファイルを保存する操作もしくは送信メールにファイルを添付する操作がある。また、印刷用ダイアログを表示する操作とは、ワードプロセッサや表計算ソフトで印刷機能を選択する操作が該当する。
 ファイル操作監視モジュール350は、クライアントPC121上のアプリケーションプログラム208のウィンドウ上でマウスボタンのクリック操作、または、ウィンドウ内に表示されたオブジェクトのドラッグ&ドロップなどの操作が行われたことを検知する操作検知機能351と、マウスを用いて操作されたファイルに対し、そのファイルの入手元に関する情報の付与、および、付与された入手元に関する情報の検査を実行する入手元情報付与・検査機能352とを実現するものである。
 ここで、マウスボタンのクリックによるファイル操作とは、例えば、Webブラウザの画面上に表示されたリンクを右クリックし、表示されたメニューに、リンクが指し示すオブジェクトをファイルとして保存する操作、または、メーラの受信メッセージ画面に添付されていたファイルをドラッグ&ドロップして、デスクトップ上にコピーする操作が該当する。
 TCP通信監視モジュール360は、ユーザがクライアントPC121 上のネットワークアプリケーションで操作を行った結果、ネットワークを介してファイルの送受信が行われたことを検知するソケット受信検知機能361と、前記ソケットを介して送受信されたデータを解析するプロトコル解析機能362と、ソケットを介してファイルがクライアントPC121にダウンロードされた場合に、そのファイルの入手元に関する情報を入手元DB393に登録するとともに、そのファイルの入手元に関する情報を入手元情報付与・検査モジュール342、352に通知する登録・通知機能363を持つ。
 上記で説明した各監視モジュールは、検知した内容に応じて、他の監視モジュールまたは入手元DB393と通信する機能と、監視モジュール制御302およびマネージャ通信機構301を介してマネージャ112にアラートを送信する機能と、アラート及び/または検知内容ログを生成する機能とを持つことができる。
 なお、以後の説明では、ファイルに関する情報などの表現にて本発明に関する情報を説明するが、これら情報は、テーブル等のデータ構造以外で表現されてもよい。そのため、データ構造に依存しないことを示すために、「ファイルに関する情報」等について、単に「情報」と呼ぶことがある。同様に、DBとして説明した部分についても必ずしもデータベースとしてのデータ構造を有することは必須ではないため、DBとした説明についても単に「情報」と呼ぶことがある。
 また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ID」という表現を用いるが、これらについては互いに置換が可能である。
 さらに、以後の説明では、「プログラム」を主語として説明を行う場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理をメモリ及び通信ポート(通信制御装置)を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ111等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、本発明は必ずしもスレッド機構を用いて実現する必要なく、マイクロスレッドやプロセス機構等OSが提供するプログラムの実行を管理する機構によって実行できればいかような機構を用いても良い。
 また、各種プログラムは、プログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
 なお、管理計算機111は入出力装置を有する。この入出力装置の例としては、ディスプレイとキーボードとポインタデバイスを挙げることができるが、これ以外の装置であってもよい。また、入出力装置の代替として、シリアルインターフェースやイーサーネットインターフェースを入出力装置とし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機で表示を行い、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。
 次に、ユーザが、クライアントPCへのインポート操作を行ったことを検出し、インポート操作されたことを示す識別子を付与する第一の手段を実現するシーケンスを図4~図7に従って説明する。
 図4は、ユーザがWebブラウザでファイルをダウンロードする際に、ブラウザ監視モジュール330とダイアログ操作監視モジュール340が実行する処理の流れを示すシーケンスの一例である。
 ユーザがWebブラウザに表示されたリンクの左クリック操作(401)を行うと、Webブラウザでは、ページ遷移のユーザ操作イベントが発生し、ブラウザ監視モジュール330は、ページ遷移のユーザ操作イベントを検知する(402)。ブラウザ監視モジュール330は、遷移後のURL(すなわちクリックされたリンク先のオブジェクトのURL)を保存し、ダイアログ操作監視モジュール340からの情報提供リクエストを待つ(403)。
 一方、左クリック操作(401)により、リンクで指定されたオブジェクトが、Webブラウザでインライン表示できないタイプのものである場合、ファイルダウンロードダイアログが表示される。この場合、ダイアログ操作監視モジュール340は、ファイルダウンロードダイアログが表示されたときに、ダイアログ操作イベントを検知し(404)、ブラウザ監視モジュール330に遷移後URL情報の提供をリクエストし、その後、ブラウザ監視モジュール330から遷移後URL情報を入手する(405)。
 前記ファイルダウンロードダイアログで保存ボタンがクリックされると、ダイアログ操作監視モジュール340は、ダイアログに表示された情報(OS207の処理による情報)から保存先ファイル名を入手し、前記ファイルの保存先情報としてフルパスを取得する(406)。さらにダイアログ操作監視モジュールは、ステップ405で入手した遷移後URLに含まれるサーバが、組織内Webサーバ116であった場合には、前記ファイルに入手元を示す識別子を付与する(407)。この識別子は、クライアントPC121が利用するローカルファイルシステム204として、Microsoft(登録商標)社のNTFS(NT File System)が用いられている場合、「代替ストリーム」を用いて実現することができる。
 図5は、ユーザがWebブラウザでファイルをダウンロードする際に、ブラウザ監視モジュール330とダイアログ操作監視モジュール340、およびファイル操作監視モジュール350が実行する処理の流れを示すシーケンスの一例である。
 ユーザがWebブラウザでページを表示すると、ブラウザ監視モジュール330は、ページ遷移のユーザ操作イベントを検知する(501)。この際Webブラウザは、遷移後のURLおよびページソースを保持し、ブラウザ監視モジュール330の要求に応じてそれらを渡すことができるようになる。この状態でWebブラウザに表示されているリンクに対して、ユーザが右クリック操作を行うと(503)、マウス操作イベントが発生し、ファイル操作監視モジュール350は前記イベントを検知する(505)。
 マウス操作イベントの発生を検知したファイル操作監視モジュール350は、Webブラウザ上でマウス操作イベントが発生した位置に関する情報をオブジェクト関連情報として保存し、ブラウザ監視モジュール330に送付する(506)。
 ブラウザ監視モジュール330は、Webブラウザでページが表示されるたびに遷移後のページのURLおよび、ページのソースを保存する(502)。
 ユーザの右クリックにより、表示されたコンテキストメニューの中から、「ファイルの保存」に関する項目が選択されると(504)、ファイル保存ダイアログが表示される。
 ダイアログ操作監視モジュール340は、前記のダイアログ表示イベントを検知すると(507)、ブラウザ監視モジュール330から、表示されたページのURLおよびページソース(ページデータ)を取得する(508)。さらに、ダイアログ操作監視モジュール340は、前記ファイルが保存されたファイルパスを取得し(510)、前記ファイルのURLに含まれるサーバが組織内Webサーバ116である場合には、ファイルの入手元が監視対象であるとして、ファイルに入手元を示す識別子を付与する(511)。
 図6は、ユーザがメールに添付されたファイルをメーラでローカルシステム204に保存する際に、TCP通信監視モジュール360と、ダイアログ操作監視モジュール340が実行する処理の流れを示すシーケンスの一例である。
 ユーザがメーラを起動したり、メールの表示操作を実行したりするなどのメッセージ受信操作を行うと(601)、POP(Post Office Protocol)3やIMAP(Internet Message Access Protocol )4などのプロトコルに従い、メールサーバ114からメッセージがダウンロードされる。すると、ネットワークドライバまたはTCP/IPプロトコルスタックの中でソケットを監視するTCP通信監視モジュール360は、メール本文データの解析処理を実施し(603)、メッセージ内の送信者名および添付ファイル名を取得する(604)。
 さらにTCP通信監視モジュール360は、Base64等でコード化された添付ファイルデータをデコードし、ハッシュ値を計算する(605)。ステップ604およびステップ605により得られた添付ファイル名、ハッシュ値、および添付ファイルの送信者名は、入手元DB393に登録しておく(606)。
 ユーザが、メーラを用いてメール本文を閲覧している最中に、添付ファイルをローカルファイルシステム204に保存する操作を実行しようとすることがある(この操作は、メールデータをダウンロードした直後ではなく、相当の時間をあけて実行されることがある)。メーラが、ファイル保存ダイアログを用いて添付ファイルを保存する操作を行うと(602)、ダイアログ操作監視モジュール340は、ダイアログ表示イベントを検知し(607)、ダイアログに表示された情報からファイル名を入手し(608)、ファイルの保存先のフルパスを入手する(609)。さらに、前記ダイアログに表示されたファイル名をキーとして入手元DB393を検索し、ファイルの送信者名などの属性を取得する(610)。
 ここで、添付ファイル名が一般的な名称、例えば「仕様書.doc」といったものである場合、入手元DB393には、複数のレコードが登録されている場合も考えられる。そのような場合には、ステップ608で入手した保存先ファイル名のファイルについてハッシュ値を計算し、前記ハッシュ値をキーとして入手元DB393を検索することにより、ファイルの送信者名を取得することが可能である。
 ステップ610で、ファイルの送信者が組織内の別ユーザであった場合、前記ファイルに入手元を示す識別子を付与する(611)。
 図7は、ユーザがメールに添付されたファイルをメーラでローカルファイルシステム204に保存する際に、TCP通信監視モジュール360と、ファイル操作監視モジュール350が実行する処理の流れを示すシーケンスの一例である。
 ステップ701からステップ706までの処理は、図6におけるシーケンス(ステップ601からステップ606)と同一のものである。ユーザが、メーラを用いてメール本文を閲覧している最中に、添付ファイルをローカルファイルシステム204に保存する操作としては、ファイル保存ダイアログを用いて行う方法だけではなく、メーラ画面内に表示された添付ファイルを示すアイコンをデスクトップやファイルエクスプローラにドラッグ&ドロップする方法もある。
 このような操作を行う場合、ファイル操作監視モジュール350は、メーラ画面からのマウスによるドラッグ&ドロップイベントを検知する(707)。さらに、ファイル操作監視モジュール350は、ファイルシステムに対するファイル生成イベントを監視し、マウスによるドラッグ&ドロップ操作に応答して、ローカルファイルシステム204で生成されたファイルの名称の取得(708)、およびフルパスを取得し
(709)、ファイル名およびファイルのハッシュ値をキーとして入手元DB393を検索し、ファイルの送信者名などの属性を取得する(710)。ステップ710においてファイルの送信者が組織内の別ユーザであった場合、前記ファイルに入手元を示す識別子を付与する(711)。
 次に、ユーザがクライアントPCからのエクスポート操作を行ったことを検出し、インポートされたことを示す識別子を確認し、アラートを送信する第二の手段を実現するシーケンスを図8~図11に従って説明する。
 図8は、ユーザがWebブラウザを用いてファイルをアップロードする際に、ブラウザ監視モジュール330とダイアログ操作監視モジュール340がそれぞれ実行する処理の流れを示すシーケンスの一例である。
 Webブラウザに表示された、ファイルアップロードに使用するフォーム画面で、ユーザが、アップロード対象のファイルを追加するボタンをクリックすると(801)、Webブラウザは、ファイル選択ダイアログを表示する。ダイアログ操作監視モジュール340は、ファイル選択ダイアログが表示されたイベントを検知し、選択されたファイルの名称を取得するとともに、ファイルオープンの監視を開始する(805)。
 ユーザが、ファイル選択ダイアログを用いてファイルを選択し、前記フォーム画面においてファイル登録ボタンをクリックすると(802)、フォーム画面がサブミットされて、Webブラウザに表示された画面が遷移する。
 ブラウザ監視モジュール330は、その結果発生するページ遷移イベントを検知し(803)、遷移後のURLを保存する(804)。
 このとき、ファイルアップロードがサブミットされた場合、ダイアログ操作監視モジュール340は、該当ファイルに対するファイルオープンを検知し(806)、該当ファイルのファイルパスをOS207から取得する(807)。
 ダイアログ操作監視モジュール340は、アラート条件を満たすか否かを判定し、アラート条件を満たすと判断した場合にアラートをマネージャ112に送信する(809)。ダイアログ操作監視モジュール340は、ブラウザ監視モジュール330から、ページ遷移後のURLを取得し、ファイルの出力先が検査対象であるか否かを判定し、ファイルをアップロードしたWebサーバが組織外のサーバであった場合、ファイルの出力先が検査対象であるとして、ファイルの入手元の識別子を確認する。ダイアログ操作監視モジュール340は、組織内のファイルサーバ115からコピーされたファイル、または、組織内Webサーバ116からダウンロードされたファイル、または、メーラに添付されて取得されたファイルがアップロード対象のファイルである場合、アラートを出力する処理を実施する(809)。
 アラートを出力する処理とは、所定のアラート条件に一致した場合に、アラートを管理サーバ111のマネージャ112に送信する処理である。
 所定のアラート条件は、ファイルのアップロード先サーバが組織外Webサーバ131のような監視対象であって、かつ、アップロード対象のファイルが管理対象である場合にアラートを送信するように設定されている。
 クライアントPC121から出力される出力情報の出力先、即ち、例えば、ファイルをアップロードしたWebサーバが組織外Webサーバ131の場合、そのWebサーバ131は、管理サーバ111の管理対象とは異なる検査対象である。
 管理サーバ111による管理対象のファイルとは、クライアントPC121で処理されたファイルが、例えば、(1)組織内のファイルサーバ115からコピーされたファイル、(2)組織内Webサーバ116からダウンロードされたファイル、(3)メーラに添付されて取得したファイル、のいずれかに該当するファイルである。このように、ファイルの入手元が管理サーバ111の管理対象である場合、クライアントPC121から出力される出力情報(ファイル)は、不正操作によって生成された情報であると判断される。その結果、不正操作の条件(アラート条件)に適合する旨のアラートが生成され、そのアラートは管理サーバ111に送信される。
 この場合、管理サーバ111は、情報漏洩事故につながるリスクの高い不正操作が検出されたと判断し、不正操作に伴う情報を、アラートで処理すべき情報として管理する。これにより、管理者は、管理サーバ111に収集されたアラートを基に、情報漏洩を抑制するための対策などを実行することができる。
 図9は、ユーザがメーラを用いて添付ファイル付きメールを送信する際に、TCP通信監視モジュール360とダイアログ操作監視モジュール340が実行する処理の流れを示すシーケンスの一例である。
 ユーザが、メーラで送信メールを作成中に、ファイル選択ダイアログを用いてファイル添付操作を行うと(901)、ダイアログ操作監視モジュール340は、ファイル選択ダイアログの表示イベントを検知し(906)、選択されたファイルの名称およびファイルのフルパスを取得して(907)、メールが送信されるまで待機する。
 この後、ユーザが、メーラでメール送信操作を実施すると(902)、TCP通信監視モジュール360は、SMTP(Simple Mail Transfer Protocol)のプロトコルで送信されるデータを解析し(903)、送信先および添付ファイル名を取得する(904)。
 送信メールに添付ファイルがつけられており、かつ、メール送信先が組織外であった場合、TCP通信監視モジュール360は、待機中のダイアログ操作監視モジュール340に、メールが組織外のあて先に送信されたことを通知する(905)。
 ダイアログ操作監視モジュール340は、送信されたファイルの入手元を示す識別子を確認し、組織内のファイルサーバからコピーされたファイル、または、組織内のWebサーバからダウンロードされたファイル、または、メーラに添付されて取得したファイルのいずれかであった場合には、アラートを出力する処理を実施する(908)。
 図10は、ユーザがメーラを用いて添付ファイル付きメールを送信する際に、TCP通信監視モジュール360とファイル操作監視モジュール350が実行する処理の流れを示すシーケンスの一例である。
 ユーザが、メーラで送信メールを作成中に、ドラッグ&ドロップを用いてファイル添付操作を行うと(1001)、ファイル操作監視モジュール350は、ファイルエクスプローラ等から、メーラのウィンドウにファイルがドラッグ&ドロップされたことを検知し(1006)、選択されたファイルの名称およびファイルのフルパスを取得して(1007)、メールが送信されるまで待機する。
 この後、ユーザが、メーラでメール送信操作を実施すると(1002)、TCP通信監視モジュール360は、SMTPのプロトコルで送信されるデータを解析し(1003)、送信先および添付ファイル名を取得する(1004)。
 送信メールに添付ファイルがつけられており、かつ、メール送信先が組織外であった場合、TCP通信監視モジュール360は、待機中のダイアログ操作監視モジュール340に、メールが組織外のあて先に送信されたことを通知する(1005)。
 ファイル操作監視モジュール350は、送信されたファイルの入手元を示す識別子を確認し、組織内のファイルサーバからコピーされたファイル、または、組織内のWebサーバからダウンロードされたファイル、または、メーラに添付されて取得したファイルのいずれかであった場合には、アラートを出力する処理を実施する(1008)。
 図11は、ユーザがアプリケーションで印刷操作を行う際に、ダイアログ操作監視モジュール340が実行する処理の流れを示すシーケンスの一例である。
 ユーザが、アプリケーションで印刷操作を行うと(1101)、ダイアログ操作監視モジュール340は、印刷ダイアログの表示イベントを検知し(1103)、印刷を実施するアプリケーションのウィンドウタイトルを取得する(1104)。これにより、ダイアログ操作監視モジュール340は、アプリケーションがオープンして、印刷を実行しようとしているファイルのフルパスを取得する(1105)。
 この後、ユーザが、印刷ダイアログにおいて印刷ボタンをクリックすると(1102)、ダイアログ操作監視モジュール340は、ダイアログがクローズされたことを検知し(1206)、送信されたファイルの入手元を示す識別子を確認し、組織内のファイルサーバからコピーされたファイルや、組織内のWebサーバからダウンロードされたファイルや、メーラに添付されて取得したファイルであった場合にはアラートを出力する処理を実施する(1107)。
 図12には、2つのシーケンスが表示されている。図12の上側には、ユーザが、ファイルエクスプローラを用いて、ファイルサーバ115の情報をローカルファイルシステム204にコピーする際に、ファイル操作監視モジュール350により実行される処理により実現される第一の手段のシーケンスが示されている。図12の下側には、ユーザが、ファイルエクスプローラを用いて、ファイルをリムーバブルメディアにコピーする際に、ファイル操作監視モジュール350により実行される処理により実現される第二の手段のシーケンスが示されている。
 第一の手段に相当するシーケンスを先に説明する。ユーザが、ファイルエクスプローラを用いたファイルのコピー、もしくは移動操作を行うと(1201)、ファイル操作監視モジュール350は、ファイルのコピー元とコピー先を特定する(1202)。ファイル操作監視モジュール350は、コピー元がファイルサーバ115で、かつ、コピー先がクライアントPC121であった場合には、操作対象のファイルに入手元を示す識別子を付与する(1203)。
 第二の手段に相当するシーケンスを説明する。ユーザが、ファイルエクスプローラを用いてファイルのコピー、もしくは移動操作を行うと(1211)、ファイル操作監視モジュール350は、ファイルのコピー元とコピー先を特定する(1212)。ファイル操作監視モジュール350は、コピー元がクライアントPC121のローカルファイルシステム204で、かつ、コピー先がクライアントPC121に接続されたリムーバブルメディアであった場合には、操作対象のファイルに入手元を示す識別子を確認する。ファイル操作監視モジュール350は、操作対象のファイルが組織内のからコピーされたファイル、または、組織内のWebサーバからダウンロードされたファイル、または、メーラに添付されて取得されたファイルのいずれかであった場合には、アラートを出力する処理を実施する(1213)。
 図13は、受信したメールに関する情報を格納するために使用する入手元DB393および、ローカルファイルシステム204に格納されたファイルに付与する入手元を示す識別子1311のフォーマットの一例である。
 入手元DB393は、ファイル名を格納するフィールド1301と、メールの送信者名を格納するフィールド1302と、フィールド1301に記載されたファイルのハッシュ値を格納するフィールド1303により構成されている。
 入手元を示す識別子1311は、図5でも述べたように、Microsoft社のNTFSであれば「代替ストリーム」を用いて、iniファイル形式のデータとして実現することができる。メールサーバ114から入手したファイルであれば、From行に送信者のメールアドレスが記載される。ファイルサーバ115から入手したファイルであれば、Server行にファイルサーバのサーバ名もしくはIPアドレスが記載される。組織内Webサーバから入手したファイルであれば、入手したファイルを示すURLが記載される。未使用の行は消去してあってもよいし、イコール以降が空白であってもよい。
 本発明では、入手元を示す識別子1311に含まれる内容を、第二の手段でアラートとして管理サーバ111に送信できる。第一の手段によって、管理対象の情報がクライアントPC121にインポートされた時刻を入手元識別子1311に含ませる場合、エクスポートされた情報の入手元以外に、入手日時もアラートの中身に含めることができる。
 上記を実現するために入手元DB393のフィールドとして、添付ファイルを含むメールを受信した時刻を格納するための時刻情報フィールドを追加してもよい。TCP通信モジュール360が、ステップ606、706において、メールヘッダに記載された受信時刻を時刻情報フィールドに登録し、ファイル属性を取得するステップ610、710において、時刻情報フィールドの記録時刻も取得して、入手元識別子1311に時刻情報を付与する構成でもよい。
 図14は、ブラウザ監視モジュール330が実行する処理の概要を示すフローチャートの一例である。
 ブラウザ監視モジュール330は、Webブラウザが起動されたタイミングで起動され、図4、図5、図8で説明したWebブラウザに対するユーザ操作イベントの監視を設定し(1401)、イベントが発生したかを判別するループに入る(1402)。イベントの発生を検知した場合、ブラウザ監視モジュール330は、ユーザの左クリック操作でページが遷移したかどうかを判別するステップを実行する(1403)。
 ユーザの左クリック操作でページが遷移した場合には、ブラウザ監視モジュール330は、遷移後のURLを取得するステップ(1404)を実行後、ダイアログ監視モジュール340にURLを送信するステップ(1408)を実行する。
 一方、ページが遷移しなかった場合には、ブラウザ監視モジュール330は、ファイル操作監視モジュール350よりマウスイベントのブラウザ上の座標情報を取得するステップ(1405)を実行する。ブラウザ監視モジュール330は、マウスカーソルの下に位置するHTMLのアンカータグを取得するステップ(1406)を実行し、マウスカーソルで選択したURLを抽出するステップ(1407)を実行する。ブザー監視モジュール330は、ダイアログ監視モジュール340にURLを送信するステップ(1404)を実行する。
 図15は、ダイアログ操作監視モジュール340が実行する処理の概要を示すフローチャートの一例である。
 ダイアログ操作監視モジュール340は、ユーザがクライアントPC121にログオンしたタイミングで起動される。ダイアログ操作監視モジュール340は、図4、図5、図6、図8、図9、図11で説明したダイアログを用いたファイル操作を監視するもので、例えば、タイマー監視等のセットアップ(1501)を行った後、ダイアログが表示されるイベントを監視する(1502)。
 イベントが発生した場合、ダイアログ操作監視モジュール340は、アップロードダイアログまたはダウンロードダイアログのいずれが表示されているかをチェックし(1503)、いずれかのダイアログが表示されていた場合には、そのダイアログを表示させたアプリケーションの種別を判別する(1504)。アプリケーションがメーラであった場合には、メーラチェックスレッドを生成するステップ(1505)、Webブラウザであった場合には、Webブラウザチェックスレッドを生成するステップ(1506)を実施する。
 また、ステップ1503において、表示されているダイアログがアップロードダイアログまたはダウンロードダイアログのいずれでもない場合、ダイアログ操作監視モジュール340は、その表示されたダイアログが印刷用ダイアログであるか否かを判別する(1507)。ダイアログ操作監視モジュール340は、印刷用ダイアログの場合、印刷チェックスレッドを生成するステップ(1508)を実施する。
 各スレッドを生成するステップを実施した後、ダイアログ操作監視モジュール340は、ダイアログが表示されるイベントを監視するステップ(1502)に戻る。
 図16は、ダイアログ操作監視モジュール340が実行する処理のうち、メーラチェックスレッドの生成ステップ1505の概要を示すフローチャートの一例である。
 本スレッドでは、ダイアログ操作監視モジュール340は、アップロードダイアログまたはダウンロードダイアログのいずれかが表示されているかをチェックし(1601)、いずれかのダイアログが表示されている場合には、ダイアログに表示されている文字列からフォルダ名の取得(1602)と、ファイル名の取得(1603)を行う。ダイアログ操作監視モジュール340は、アップロード対象またはダウンロード対象のファイルのフルパスを構成した上で(1604)、ステップ1601に戻る。
 この後、ユーザが、ダイアログの保存ボタン等をクリックしてダイアログが非表示になると、ステップ1611以降の処理を実行する。
 まず、ダイアログ操作監視モジュール340は、ステップ1604によりフルパスが取得されており、かつ、そのフルパスで示されるファイルが存在するか判別する(1611)。ダイアログ操作監視モジュール340は、ファイルが存在する場合にはステップ1612以降の処理を実行し、ファイルが存在しない場合にはステップ1601に戻る。
 ファイルが存在する場合、ダイアログ操作監視モジュール340は、まずダウンロードダイアログか否かを判別し(1612)、ダウンロードダイアログである場合には、ステップ1604で特定されるファイルのハッシュ値を計算する(1613)。ダイアログ操作監視モジュール340は、図6、図7で示したように、TCP通信監視モジュール360が入手元DB393に登録した情報を検索し(1614)、入手元が組織内の他ユーザである場合など所定の条件に一致する場合、ステップ1604で取得されるフルパスで特定されるファイルに、入手元情報を書き込む(1609)。
 アップロードダイアログの場合、ダイアログ操作監視モジュール340は、図9、図10で示したように、TCP通信モジュール360から送信先情報を受信し(1621)、アップロードダイアログで指定されたファイルがメールに添付されて送信された場合、ステップ1604で特定されるファイルの入手元情報を読み込む(1622)。ダイアログ操作監視モジュール340は、アラート条件をチェックしてアラートを生成し、必要に応じてアラートを管理サーバ111に送信する(1623)。
 図17は、ダイアログ操作監視モジュール340が実行する処理のうち、Webブラウザチェックスレッドの生成ステップ1506の概要を示すフローチャートの一例である。
 本スレッドでは、ダイアログ操作監視モジュール340は、アップロードダイアログまたはダウンロードダイアログのいずれかが表示されているかをチェックし(1701)、いずれかのダイアログが表示されている場合には、ダイアログに表示されている文字列からフォルダ名の取得(1702)と、ファイル名の取得(1703)を行い、アップロード対象またはダウンロード対象のファイルのフルパスを構成して(1704)、ステップ1701に戻る。この後、ユーザが、ダイアログの保存ボタン等をクリックしてダイアログが非表示になると、ステップ1705以降の処理を実行する。
 まず、ダイアログ操作監視モジュール340は、ステップ1704によりフルパスが取得されており、かつフルパスで示されるファイルが存在するかを判別する(1705)。ダイアログ操作監視モジュール340は、ファイルが存在する場合にはステップ1706以降の処理を実行し、ファイルが存在しない場合にはステップ1701に戻る。ダイアログ操作監視モジュール340は、ファイルが存在する場合、まずダウンロードダイアログか否かを判別し(1706)、ダウンロードダイアログであった場合には、図4、図5で示したようにブラウザ監視モジュール330が保持するダウンロード元情報を入手し(1707)、入手元が組織内の他ユーザであるなど所定の条件に一致する場合、ステップ1704で取得されたフルパスで示されるファイルに、入手元情報を書き込む(1708)。
 アップロードダイアログであった場合には、ダイアログ操作監視モジュール340は、図8で示したように、ブラウザ監視モジュール330が保持するアップロード先情報を、ブラウザ監視モジュール330から入手する(1709)。ダイアログ操作監視モジュール340は、アップロードダイアログで指定されたファイルが送信された場合、ステップ1704で取得されたフルパスで特定されるファイルの入手元情報を読み込み(1710)、アラート条件に合致するか否かをチェックしてアラートを生成し、必要に応じてアラートを管理サーバ111に送信する(1711)。
 図18は、ダイアログ操作監視モジュール340が実行する処理のうち、アプリケーションによる印刷チェックスレッドを生成するステップ1508の概要を示すフローチャートの一例である。
 本スレッドでは、ダイアログ操作監視モジュール340は、印刷ダイアログが表示されているかをチェックし(1801)、ダイアログが表示されている場合には、印刷元のアプリケーションプログラムのプロセスIDを取得し(1802)、さらに、そのプロセスIDで特定されるアプリケーションプログラムがオープンしているファイル一覧の中からファイル名を取得する(1803)。ダイアログ操作監視モジュール340は、印刷対象のファイルのフルパスを構成して(1804)、ステップ1801に戻る。
 この後、ユーザが、ダイアログの印刷ボタン等をクリックしてダイアログが非表示になると、ダイアログ操作監視モジュール340は、印刷対象ファイルの入手元情報を読み込み(1805)、アラート条件をチェックしてアラートを生成し、必要に応じてアラートを管理サーバ111に送信する(1806)。
 図19は、ファイル操作監視モジュール350が実行する処理の概要を示すフローチャートの一例である。
 ファイル操作監視モジュール350は、ユーザがクライアントPC121にログオンしたタイミングで起動され、マウスイベントのフックを開始(1901)した後、図5、図7、図10で説明した、マウスを用いたファイル操作を監視する。ファイル操作監視モジュール350は、イベントを検知したときには、検知したマウス操作イベントが右クリックであるか否か判別する(1902)。
 右クリック操作の場合、ファイル操作監視モジュール350は、フォアグラウンドウィンドウでのマウスカーソル座標を取得し(1903)、ブラウザウィンドウの座標への変換処理を実行し(1904)、ブラウザ監視モジュール330にステップ1904で取得した座標を通知する処理を実行し(1905)、イベント監視に戻る。
 一方、ステップ1902で、マウス操作イベントが右クリックでないと判定した場合には、ファイル操作監視モジュール350は、ドラッグイベントであるかを判別する処理を実行し(1911)、ドラッグイベントでなかった場合にはイベント監視に戻る。
 イベントがドラッグイベントである場合は、ファイル操作監視モジュール350は、ドラッグされたオブジェクトがドロップされるイベントを検出し、ファイルエクスプローラ上でドラッグされたファイルが、メーラ上でドロップされたかを判定する(1912)。
 ステップ1912でNoと判定された場合には、ファイル操作監視モジュール350は、後述のステップ1921に移る。ステップ1912でYesと判定された場合、ファイル操作監視モジュール350は、ドラッグ元ファイルパスを取得し(1913)、ステップ1913で取得したフルパスで特定されるファイルの入手元情報を読み込み(1914)、アラート条件をチェックした上で必要に応じてアラートを管理サーバ111に送信する(1915)。
 ステップ1912で、オブジェクトのドロップされた先がメーラ上でない場合、ファイル操作監視モジュール350は、ドラッグ&ドロップイベントが、メーラ上でドラッグされ、ファイルエクスプローラ上でドロップされたかを判定する(1921)。
 ステップ1921がNoと判定された場合、ファイル操作監視モジュール350は、イベント監視に戻り、ステップ1921でYesと判定された場合には、メールに添付されたファイルのドロップ先のファイルパスを取得する(1922)。次に、ファイル操作監視モジュール350は、ステップ1922でフルパスが取得されたファイルのハッシュ値を計算し(1923)、入手元DB393に登録した情報を検索する(1924)。ファイル操作監視モジュール350は、入手元が組織内の他ユーザである場合など所定の条件に一致する場合、ステップ1922で取得されたフルパスで示されるファイルに、入手元情報を書き込む(1915)。
 なお、図12で示したシーケンスに対するファイル操作監視モジュール350の処理も、ドラッグ元がファイルサーバ115でドロップ先がローカルファイルシステム204である場合には、ステップ1922とステップ1925に準じる処理を、ドラッグ元がローカルファイルシステム204で、ドロップ先がリムーバブルメディアであった場合にはステップ1913とステップ1915に準じる処理を行えばよい。
 また、ドラッグ元がファイルサーバ115で、ドロップ先がリムーバブルメディア125であった場合には、ステップ1915に準じる処理を行えばよい。
 図20は、TCP通信監視モジュール360が実行する処理の概要を示すフローチャートの一例である。
 TCP通信監視モジュール360は、ユーザがクライアントPC121にログオンしたタイミングで起動され、SMTP、POP3、IMAP4の各プロトコルでの通信データを監視する。TCP通信監視モジュール360は、ソケット通信の監視を開始し(2001)、前記各プロトコルのいずれかでの送受信データかどうかを判別する(2002)。ステップ2002がNoの場合、ソケット通信の監視に戻り、Yesの場合はステップ2003以降の処理を実施する。
 ステップ2003では、TCP通信監視モジュール360は、メールデータの解析を実施する。この際、メールデータのヘッダ領域から送信者および受信者の情報を解析でき、さらに、MIME(Multipurpose Internet Mail Extension)パートの解析により添付ファイルの有無およびファイル名称等の情報を得ることができる。
 次に、TCP通信監視モジュール360は、メールに添付ファイルがあるかどうか識別し(2004)、添付されている場合は、さらにプロトコル種別がメール受信用のPOP3もしくはIMAP4のいずれかであるか、または、メール送信用のSMTPであるかを判別する(2005)。メール受信の場合、TCP通信監視モジュール360は、送信者名と添付ファイル名を取得し(2006)、添付ファイルのデータをデコードした後でハッシュ値を計算し(2007)、さらに、入手元DB393への登録を行ってから、ソケット通信の監視に戻る。
 一方、ステップ2005で、メール送信と判定された場合、TCP通信監視モジュール360は、送信者名と添付ファイル名を取得し(2009)、ダイアログ監視モジュール350およびファイル監視モジュール360に、ステップ2009で取得した情報を送付する(2010)。
 以上の構成および処理により、本システムでは、監視対象とは異なる機器からクライアントPC121にインポートされた情報(入力情報)が、検査対象となる機器にエクスポートされたことを識別することが可能となる。クライアントPC121に情報をインポートする方法としては、
(1)Webブラウザでのダウンロード、
(2)受信メールに添付されたファイル
(3)ファイルエクスプローラを用いた、ファイルサーバからローカルファイルシステム204へのコピーおよび移動、
がある。
 それらのいずれの操作でも、インポートされた情報には、インポート元に関する情報を含む入手元を示す識別子1311が付与される。
 クライアントPC121のローカルファイルシステム内でインポートされた情報に、コピー、または、名前変更、または、移動の各処理を行った場合、処理後の情報(コピーされた情報を含む)にも入手元を示す識別子1311が付与される機能が備わっているファイルシステム(例えばMicrosoft社のNTFS)であれば、
 本実施例の不正操作検知システムが想定する、情報エクスポート操作として、
 (1)Webブラウザでのファイルアップロード、
 (2)添付ファイル付きメールの送信、
 (3)アプリケーションプログラムでの印刷、
 (4)リムーバブルメディアへのコピーおよび移動、
が行われる際に、アラートを管理サーバ111に送信可能である。
 本システムを用いてアラートを送信するためのアラート条件は、入手元を示す識別子1311の内容に基づいて決定してもよい。例えば、Webブラウザを用いたダウンロードによりインポートされた情報であれば、組織内の全てのWebサーバを対象としてもよく、または、重要な情報が格納されているWebサーバを識別できるのであれば、特定のWebサーバのURLが入手元を示す識別子1311に含まれている場合のみを対象とするように、セキュリティポリシ392に設定してもよい。
 また、エクスポート操作を行う時間帯や、情報の種別、サイズに応じてアラートを出力する条件を変えることも可能である。
 本実施例によれば、組織内の他の計算機で作成された機密情報を、ユーザが自分の使用するクライアントPC121にインポートした後で、組織外にエクスポートした操作を、不正操作として検出することが可能である。従って、本実施例では、ユーザが行った情報漏洩につながるリスクの高い操作を不正操作として検出することができる。
 これにより、情報漏洩につながるリスクの高いユーザの操作を検知するために、特定の情報出力操作が行われた場合にアラートを出力する初期設定や、不正な操作パターンを定義する初期設定を行わずに、情報漏洩のリスクの高い不正操作に対して、アラートを上げる機能を実現することができる。
 また、情報漏洩事故につながるリスクの高い不正操作を検出し、不正操作に伴う情報を、アラートで処理すべき情報として管理することで、情報漏洩を抑制できる。
 図23-図40を参照して第2実施例を説明する。本実施例では、ファイル操作の履歴を管理するためのインファイルトレース情報を各ファイル内に記憶させ、さらに、インファイルトレース情報と同一の情報を管理サーバ111にも記憶させる。本実施例を含む以下の各実施例では、上述した実施例と異なる部分を中心に説明する。
 図23は、インファイルトレース情報が生成される様子を示す。インファイルトレース情報は、例えば、どのファイルのどの世代の何回目のコピーであるかを示す情報であり、例えば、NTFSの代替データストリーム(以下、代替ストリーム)に記録される。後述のように、インファイルトレース情報を参照することにより、各ファイル間の関係を比較的簡単に把握でき、ファイル間の関係をツリー構造で表示することができる。
 ユーザがファイルを新たに作成すると、そのファイル作成は、ファイル操作監視モジュール350により検出される。ファイル操作監視モジュール350は、インファイルトレース情報を作成する(3001)。作成されたインファイルトレース情報は、ファイル3002の代替ストリームに格納される。さらに、エージェントプログラム122は、作成されたインファイルトレース情報をマネージャ112に送信する。これにより、PC管理DBにも、インファイルトレース情報と同一の情報が格納される(図29の3101)。
 インファイルトレース情報は、例えば、ファイル格納識別子(FID)と、操作識別子(OID)と、カウントとを備える。ファイル格納識別子は、ファイルがクライアントPC121の有するファイルシステム204に格納される場合に設定される情報であり、そのファイルを一意に特定するための情報である。操作識別子は、「操作世代情報」に該当し、ファイル操作の回数(世代)を示す情報である。カウントは、「コピー回数情報」に該当し、ファイルがコピーされた回数を示す。換言すれば、カウントは、ファイルから枝分かれした系統の数を示す。
 なお、ファイル3002内に示されている”カウント”は、次の操作識別子を生成するためにも使用される。つまり、一回コピーされる度に系統が一つ増加するため、どの系統のファイルの何回目の操作であるかを示すために、操作元ファイル内のカウントの値は、操作先のファイルの操作識別子に受け継がれる。
 次に、ファイル3002がコピーされた場合、ファイル操作監視モジュール350は、ファイル3002の代替ストリームからインファイルトレース情報を取得し、コピー操作後のインファイルトレース情報を作成する(3003)。作成されたインファイルトレース情報(3003)は、コピー先のファイル3004の代替ストリームに格納される。さらに、そのインファイルトレース情報と同一の情報が、コピー先ファイルに対応付けられて、PC管理DBに格納される。
 コピー操作に伴って、コピー元のファイル3002のカウントの値は、”0”から”1”に更新される。ファイルのコピーは、コピー元を残したままで、同一内容のファイルを新たに作成することを意味する。即ち、同一内容のファイルが複数併存することになる。そこで、コピー回数に応じてカウントの値を更新し、コピー毎の系統を区別する。
 ファイル操作はコピーであり、操作元のファイル3002はコピー元のファイルであり、操作先のファイル3004はコピー先のファイルである。コピー元ファイル3002とコピー先ファイル3004とは、同一のファイルデータを有する。従って、コピー元ファイル3002のファイル格納識別子とコピー先ファイル3004のファイル格納識別子とは同一である。
 操作識別子の変化に着目する。コピー元ファイル3002の操作識別子は”0”である。コピー先ファイル3004の操作識別子は”00”である。操作の回数が1つ増加するたびに、操作識別子の桁数が1つ増加する。操作先ファイルの操作識別子は、操作元ファイルの操作識別子及びカウントから構成される。操作元ファイル3002の操作識別子は”0”であり、カウントも"0"である。従って、操作先ファイル3004の操作識別子は、操作元ファイル3002の操作識別子"0"と、操作元ファイル3002のカウント"0"とを並べることにより、"00"として作成される。
 つまり、操作識別子は、操作回数と系統(分岐の数)の両方を示す。操作識別子の桁数は、操作回数を示している。2桁なら、2回目の操作であることを示す。先の例では、1回目の操作は、ファイルの作成である。操作識別子に含まれる”0”以外の数字(または文字)は、何回目のコピーの子孫であるかを示す。例えば、操作識別子が”000”であるファイル3006は、操作識別子が"0"であるファイル3002の直系の子孫であり、3回目の操作により作成されたファイルである。
 ファイル3004の名称が手動または自動で変更された場合を説明する。この場合のファイル操作は、名称変更である。操作元ファイルは、名称変更元(名称変更前)のファイル3004である。操作先ファイルは、名称変更先(名称変更後)のファイル3006である。
 ファイル操作監視モジュール350は、ファイル3004の代替ストリームからインファイルトレース情報を取得し、名称変更後のインファイルトレース情報を作成する(3005)。作成されたインファイルトレース情報(3005)は、名称変更先のファイル3006の代替ストリームに格納される。前記同様に、そのインファイルトレース情報と同一の情報が、名称変更先ファイル3006に対応付けられて、PC管理DBに格納される。
 名称変更先ファイル3006は、名称が変更されただけであり、ファイル3004と同一のファイルデータを有する。従って、名称変更元のファイル3004のファイル格納識別子と名称変更先ファイル3006のファイル格納識別子とは同一である。
 名称変更先ファイル3006の操作識別子”000”は、名称変更元のファイル3004の操作識別子”00”とカウント"0"とを並べることにより生成される。名称変更元ファイル3006の操作識別子”000”は3桁であるから、そのファイル3006は、起点となるファイル3002の作成から数えて3回目の操作で作成されたファイルであることがわかる。なお、名称変更先ファイル3006のカウントには”0”が設定される。
 名称変更されたファイル3006が手動または自動でファイルシステム204から削除された場合を説明する。ここでのファイル操作は、ファイル削除である。操作元ファイルは、削除対象のファイル3006である。操作先ファイルは存在しない。削除されるためである。
 操作先のファイルは存在しないが、操作先ファイル用のインファイルトレース情報3007は作成される。ファイル格納識別子は、削除対象ファイル3004のファイル格納識別子と同一である。操作識別子"0000"は、削除対象ファイル3004の操作識別子”000”とカウント”0”とを並べることにより作成される。操作先ファイル用に作成されたインファイルトレース情報3007と同一の情報が、PC管理DBに格納される。
 大元のファイル3002が移動された場合を説明する。この場合、ファイル操作はファイル移動であり、操作元ファイルは移動元ファイル3002であり、操作先ファイルは移動先ファイル3009である。ファイル操作監視モジュール350は、そのファイル移動を検出すると、移動元ファイル3002のインファイルトレース情報を取得し、そのインファイルトレース情報に基づいて移動先ファイル3009のインファイルトレース情報3008を作成する。
 ファイル移動は、ファイルコピーと同様に、ファイル操作の前後でファイルデータに変化はない。従って、移動先ファイル3009のインファイルトレース情報3008において、ファイル格納識別子は、移動元ファイル3002のファイル格納識別子と同一である。移動先ファイル3009のインファイルトレース情報3008において、操作識別子"01"は、移動元ファイル3002の操作識別子"0"とカウント”1”を並べることにより生成される。なお、前記同様に、移動先ファイル3009のカウントには、初期値”0”が設定される。
 なお、ファイル移動の場合は、ファイルコピーと異なり、移動元ファイル3002は消滅し、移動先ファイル3009のみがファイルシステム204に残る。しかし、PC管理DBには、移動元ファイル3002に関するインファイルトレース情報3001が記憶され続ける。
 移動先ファイル3009が削除された場合を説明する。この場合のファイル操作はファイル削除であり、操作元ファイルは削除対象ファイル3009である。ファイルが削除されるため、操作先ファイルは存在しない。しかし、前記同様に、操作先ファイル用のインファイルトレース情報3010が作成されて、PC管理DBに記憶される。インファイルトレース情報3010において、操作識別子"010"は、削除対象ファイル3002の操作識別子"0"とカウント”1”とを並べて生成される。インファイルトレース情報3010のカウントの値には、初期値である”0”が設定される。
 図23で述べたファイル操作の履歴を、図24-図28を参照して再度説明する。図24-図28では、図23に示す各ファイル操作を一つずつ説明する。但し、図23に示す各ファイル操作のうち重複したファイル操作(ファイル削除)は、図24-図28では1つのみ示される。
 図24-図28には、インファイルトレース情報とPC管理DBの記憶内容との関係が示されている。図24の左側は初期状態を示す。初期状態では、クライアントPC121のファイルシステム204に一つもファイルが格納されておらず、PC管理DBにもレコードが記録されていない。
 図24の右側は、一つのファイル3002がファイルシステムに格納された状態を示す。例えば、Webサーバ116,131からダウンロードされたファイル、ファイルサーバ115からダウンロードされたファイル、リムーバブルメディア125からコピーされたファイル、電子メールに添付されていたファイル等のファイルが、ファイルシステムに格納される。
 ファイルシステム204にファイル3002が格納されると、そのファイル用のインファイルトレース情報3001が作成される。そのインファイルトレース情報3001では、操作識別子に”0”が設定され、カウントにも初期値”0”が設定される。PC管理DBには、インファイルトレース情報3001と同一の情報が記憶される。さらに、PC管理DBには、ファイル操作の内容(どこから取得されたファイルであるか等を示す情報)も一緒に記憶される。
 図25を参照する。図25の左側は図24の右側と同一である。従って、図25の右側の状態を説明する。図25の右側は、図24の右側でファイルシステムに格納された最初のファイル3002(C:\test.txt)が、他のディレクトリにコピーされた状態を示す。コピー先ファイル3004(C:\test\test.txt)のインファイルトレース情報3003では、操作識別子(OID)に”00”が設定され、カウントに”0”が設定される。ファイル格納識別子(FID)は、コピー前と同じである。PC管理DBには、コピー先ファイル3004のインファイルトレース情報と同一の情報3003と操作内容とが対応付けられて記憶される。
 最初のファイル3002(C:\test.txt)から一つのコピー(C:\test\test.txt)が作成されたことにより、最初のファイル3002のインファイルトレース情報に含まれるカウンタの値は、”0”から”1”に変化する。しかし、PC管理DBに記憶されている最初のファイル3002のインファイルトレース情報に対応するレコードは、コピー操作の前後で変更されない。PC管理DBに記憶されている、最初のファイル3002のインファイルトレース情報は一切変更されない。つまり、PC管理DBには、ファイル操作後のインファイルトレース情報と同一の情報が記憶され、その後に、そのインファイルトレース情報に対応するファイルがさらに操作された場合でも、操作されたファイルのインファイルトレース情報に対応するレコードの内容は変化しない。
 図26を参照する。図26の左側は図25の右側と同一である。従って、図26の右側の状態を説明する。図26の右側は、図25の右側においてコピーされたファイル3004のファイル名を”text.txt”から”text2.txt”に変更した状態を示す。
 名称変更元のファイル3004(C:\test\text.txt)のインファイルトレース情報に基づいて、名称変更先ファイル3006(C:\test\text2.txt)のインファイルトレース情報が作成される。その作成されたインファイルトレース情報は、名称変更先ファイル3006の代替ストリームに格納される。さらに、作成されたインファイルトレース情報と同一の情報3005は、PC管理DBにも記憶される。
 名称変更先ファイル3006のインファイルトレース情報において、操作識別子は”000”に設定される。名称変更元ファイル3004の操作識別子”00”とカウント”0”とを並べて3桁にすることにより、名称変更先ファイル3006に関する操作識別子”000”が生成される。名称変更先ファイル3006に関するカウントには、初期値”0”が設定される。
 図26の右下に示すPC管理DBに着目すると、PC管理DBには、最初のファイル3002に関するインファイルトレース情報(正確には、インファイルトレース情報と同一の情報に操作内容を加えた情報。以下同様)と、コピーされたファイル3004に関するインファイルトレース情報と、名称変更されたファイル3006に関するインファイルトレース情報との、合計3つのインファイルトレース情報が格納されている。上述の通り、PC管理DBに格納された各インファイルトレース情報の内容は、その後のファイル操作に関わらず、変更されない。PC管理DBに記憶される各インファイルトレース情報に基づいて、ファイル操作の変遷(履歴)検出し、可視化するためである。
 図27を参照する。図27の左側は図26の右側と同一である。従って、図27の右側の状態を説明する。図27の右側は、最初のファイル3002(C:\text.txt)を別のディレクトリ(D:\)に移動させた状態を示す。
 移動先ファイル3009(D:\text.txt)に関するインファイルトレース情報は、移動元ファイル3002(C:\text.txt)のインファイルトレース情報に基づいて作成され、移動先ファイル3009の代替ストリームに格納される。前記同様に、PC管理DBには、そのインファイルトレース情報と同一の情報が送信されて記憶される。
 移動先ファイル3009に関する操作識別子”01”は、移動元ファイル3002の操作識別子”0”とカウント”1”とを並べて2桁にすることにより作成される。カウントの値には初期値”0”が設定される。なお、図24-図28を通じて、ファイル格納識別子に変化はない。
 図28を参照する。図28の左側は図27の右側と同一であるため、図28の右側の状態を説明する。図28の右側は、図27の右側において移動されたファイル3009を、ファイルシステムから削除した状態を示す。
 削除されたファイルのインファイルトレース情報は、削除対象のファイル3009(D:\text.txt)のインファイルトレース情報に基づいて作成される。作成されたインファイルトレース情報と同一の情報3010は、PC管理DBに送信されて記憶される。作成されたインファイルトレース情報は、代替ストリームに格納されない。ファイルが削除されており、格納すべき代替ストリームが存在しないためである。
 削除されたファイルに関する操作識別子”010”は、削除対象ファイル3009の操作識別子”01”とカウント”0”を並べて3桁にすることにより作成される。削除されたファイルに関するカウントには、初期値”0”が設定される。既にファイルは削除されているため、そのカウントの値が増加することはない。
 図29は、PC管理DBの記憶例を示す。図23で示したような複数のファイル操作が実行されることにより、図29に示すような管理データがPC管理DBに格納される。PC管理DBは、各ファイル操作に対応するレコード3101-3106を有する。PC管理DBの各レコードは、例えば、ファイル格納識別子フィールド3110と、操作識別子フィールド3111と、操作種別フィールド3112と、操作元パスフィールド3113と、操作先パスフィールド3114と、を含む。このほかに、例えば、ファイルの操作日時、ファイルを操作したユーザ等の情報をPC管理DBで管理することもできる。上記各フィールドのうち、ファイル格納識別子フィールド3110及び操作識別子フィールド3111は、ファイル操作を追跡して可視化するために必須の情報である。その他のフィールドは、ファイル操作の内容を示す情報である。
 ユーザ(管理者)がファイル操作の履歴の出力を希望する場合、次のような処理が実行される。まず、ユーザは、起点となるインファイルトレース情報を選択する。管理サーバ111内のマネージャ112は、ユーザにより選択されたインファイルトレース情報に含まれるファイル格納識別子で、PC管理DBを検索する。これにより、ユーザにより選択されたファイル格納識別子を有するレコードのみが抽出される。さらに、マネージャ112は、ユーザにより選択されたファイル格納識別子を有する各レコードを、操作識別子に基づいて並び替える。
 このようにして得られる情報は、全て同一のファイルから発したファイル操作の履歴を示している。操作識別子の先頭から最終桁の1つ前までの桁が共通するインファイルトレース情報は、同一系統の操作に属する。同一系統のファイル操作に属するインファイルトレース情報において、操作識別子の桁数(操作識別子の文字数)が1つ多いインファイルトレース情報は、その次の操作を示す。
 図30は、代替ストリームに格納されるインファイルトレース情報の例を示す。この例では、iniファイルの形式で、ファイル識別子と操作識別子とカウントとを格納する。この例では、ファイル識別子には、UUID(Universally Unique Identifier)を設定し、操作識別子の桁数は32文字とし、操作識別子の使用可能な文字の範囲は0-9、A-Z、a-zとし、カウントの範囲は0から60までとする。
 図31は、ファイル操作を監視するシーケンスを示す。ユーザがエクスプローラ等のアプリケーションプログラムを用いてファイル操作(例えば、ファイルの作成、移動、コピー、名称変更、削除のいずれか)を行うと(1201)、ファイル操作監視モジュール350は、そのファイル操作を検知する。以下、ファイルコピーの場合を中心に述べる。
 ファイル操作監視モジュール350は、コピー元及びコピー先を確認し(1202)、必要に応じて、操作されたファイルの代替ストリームに入手元情報を書き込む(1203)。そして、ファイル操作監視モジュール350は、操作されたファイルの代替ストリームに、インファイルトレース情報を書き込む(3301)。
 上述の通り、エクスプローラ等のアプリケーションプログラムを用いて、ファイルが移動またはコピーされた場合、ファイルの代替ストリームの内容も、移動またはコピーされる(操作識別子の値は変化する)。ファイルが削除されると、代替ストリームの内容も削除される。
 ファイル操作監視モジュール350は、操作先のインファイルトレース情報を作成し、操作先のインファイルトレース情報をマネージャ112に送信してPC管理DBに記憶させ、さらに、必要に応じて操作元のインファイルトレース情報を更新する。インファイルトレース情報の操作の詳細は、後述する。
 図34は、図31に示すインファイルトレース情報を操作する処理3301の詳細を示すフローチャートである。まず最初に、ファイル操作監視モジュール350(以下、監視モジュール350と略記する場合がある)は、ファイル操作の起点となる操作であるか否かを判定する(3401)。ファイル操作の起点となる操作とは、ファイルの作成を意味する。例えば、Webサーバ等からクライアントPC121にファイルをダウンロードする操作は、ファイルの起点となる操作に該当する。
 起点となるファイル操作であると判定されると、監視モジュール350は、インファイルトレース情報を新規作成し(3402)、新たに作成されたファイルの代替ストリームに、新規作成されたインファイルトレース情報を書き込む(3403)。さらに、監視モジュール350は、新規作成されたインファイルトレース情報をマネージャ112に送信し、PC管理DBに記憶させる(3404)。
 起点となるファイル操作ではないと判定されると、監視モジュール350は、操作元となるファイルの代替ストリームからのインファイルトレース情報の取得を試みる(3410)。監視モジュール350は、操作元ファイルの代替ストリームからインファイルトレース情報を取得できたか否かを判定する(3411)。操作元ファイルの代替ストリームからインファイルトレース情報を取得できなかった場合、監視モジュール350は、操作元ファイル用のインファイルトレース情報を新規に作成する(3412)。
 例えば、本実施例に係るファイル操作履歴の管理システムが計算機システムに導入されるよりも前から存在するファイルの代替ストリームには、インファイルトレース情報が書き込まれていない。従って、そのようなファイルには、新たにインファイルトレース情報を作成して代替ストリームに書き込む(3412,3418)。
 監視モジュール350は、操作先ファイルに関するインファイルトレース情報を作成し、さらに、更新が必要な場合は操作元ファイルに関するインファイルトレース情報を更新させる(3413)。ステップ3411で操作元ファイルの代替ストリームからインファイルトレース情報を取得できた場合は、ステップ3413に移る。
 監視モジュール350は、ユーザの希望するファイル操作を実行し(3414)、操作先ファイルが存在するか否かを判定する(3415)。操作先ファイルが存在する場合、監視モジュール350は、ステップ3413で作成した操作先ファイルに関するインファイルトレース情報を、操作先ファイルの代替ストリームに書き込む(3416)。
 操作先ファイルが存在しない場合、監視モジュール350は、操作元ファイルが存在するか否かを判定する(3417)。操作元ファイルが存在する場合、監視モジュール350は、更新が必要ならば、ステップ3413で作成したインファイルトレース情報を操作元ファイルの代替ストリームに書き込む(3418)。例えば、ファイルコピーの場合は、操作元ファイル(コピー元ファイル)に関するインファイルトレース情報内のカウント値を増加させる必要がある。
 操作元ファイルが存在しない場合、または、操作元ファイルの代替ストリームに記憶されるインファイルトレース情報を更新した場合のいずれかの場合、監視モジュール350は、操作先ファイルに関するインファイルトレース情報をマネージャ112に送信して、PC管理DBに記憶させる(3419)。
 上述の通り、ファイルの作成、コピー、移動、名称変更の場合は、操作先のファイルが存在する。ファイルを削除する場合、操作先のファイルは存在しない。操作先ファイルが存在しない場合、ステップ3413で生成された操作先ファイル用のインファイルトレース情報は、PC管理DBでのみ管理される。
 ファイルの移動、名称変更、削除の場合、操作元ファイルは存在しなくなる。ファイルの作成またはコピーの場合のみ、操作元ファイルは存在する。
 図33は、図32中のステップ3402の詳細を示す。監視モジュール350はUUIDを生成し(3501)、インファイルトレース情報内のファイル格納識別子にUUIDを設定する(3502)。監視モジュール350は、操作識別子に初期値”0”を設定し(3503)、さらに、カウントに初期値”0”を設定する(3504)。
 図34は、図32中のステップ3413の詳細を示すフローチャートである。監視モジュール350は、操作元ファイルに関するインファイルトレース情報のコピーを作成し、操作先のインファイルトレース情報の基礎とする(3601)。
 監視モジュール350は、操作先ファイルに関するインファイルトレース情報の操作識別子の桁数が31桁よりも小さいか否かを判定する(3602)。上述の通り、操作識別子は操作されるたびに1つずつ増加し、その上限値は32である。
 操作識別子の桁数が31桁よりも小さい場合、監視モジュール350は、操作先ファイルに関するインファイルトレース情報内のカウントの値が60よりも小さいか否かを判定する(3603)。上述の通り、カウントは、コピーされるたびに1つずつ増加し、その上限値は60である。カウントの値が60未満の場合、監視モジュール350は、操作先ファイルに関する操作識別子の最後に、操作元ファイルに関するカウントから変換された文字を1つ追加する(3604)。これにより、操作先ファイルに関する操作識別子は、操作元ファイルに関する操作識別子と操作元ファイルに関するカウントとを並べた値となる。
 図35は、カウントの値を文字に変換するためのテーブルを示す。図35に示すように、カウント値が”0”から”9”までの間は、0-9が割り当てられる。カウント値が”10”から”35”までの間は、大文字のアルファベットA-Zが割り当てられる。カウント値が”36”から”59”までの間は、小文字のアルファベットa-xが割り当てられる。例えば、操作元ファイルに関する操作識別子が”000”、カウントの値が”29”の場合、操作先ファイルの操作識別子は”000”と”T(=29)”を並べた”000T”となる。
 図34に戻る。ステップ3604の後、監視モジュール350は、操作先ファイルに関するカウントに初期値”0”を設定し(3605)、さらに、カウントの更新が必要な場合には、操作元ファイルに関するカウントの値を1つ増加させる(3606)。つまり、ファイルがコピーされた場合には、操作元ファイルのカウントの値を1つ増加させる。それ以外のファイル操作の場合は、操作元ファイルのカウントの値は変化しない。
 操作先ファイルに関するカウントの値が60未満ではない場合、監視モジュール350は、不正操作であるか否かを判定する(3607)。第1実施例で述べたように、例えば、入手元識別子の設定されたファイルが外部のサーバまたはリムーバブルメディアに出力された場合には、不正操作であると判定することができる。
 不正なファイル操作であると判定された場合、監視モジュール350は、操作先ファイルに関する操作識別子の最終桁(60桁目)に、”z”を設定する(3608)。操作先ファイルに関するカウントには、”0”が設定される(3609)。
 不正なファイル操作ではないと判定された場合、監視モジュール350は、操作先ファイルに関する操作識別子の最終桁(60桁目)に、”y”を設定する(3610)。操作先ファイルに関するカウントには、”0”が設定される(3611)。
 操作識別子の桁数が31桁未満ではないと判定された場合、操作識別子の桁数が31桁であるか否かが判定される(3612)。操作識別子が31桁では無い場合、本処理は終了する。操作識別子の桁数が31桁の場合、監視モジュール350は、不正なファイル操作が行われたか否かを判定する(3613)。不正なファイル操作ではない場合、本処理は終了する。不正なファイル操作が行われた場合、監視モジュール350は、操作先ファイルに関する操作識別子の最終桁に”0”を追加して、32桁の操作識別子を生成する(3614)。
 ステップ3607及びステップ3613で、不正なファイル操作であるか否かを判定する理由について説明する。例えば、ファイルがリムーバブルメディア125に書き込まれたり、または、ファイルが組織外のWebサーバ131にアップロードされた場合、操作先ファイルの代替ストリームにインファイルトレース情報を書き込むことはできない。操作先ファイルはクライアントPC121のファイルシステム204の外部に存在するためである。従って、不正に操作された場合の操作先ファイルは、ツリー構造の末端の葉に相当する。
 ところで、データを格納可能な領域は無限でないため、本実施例では、操作識別子の桁数を32桁(32文字)、操作識別子として使用可能な文字の範囲を0-9、A-Z、a-zに制限している。
 もしも、不正操作であるか否かを問わずにファイル操作の履歴を追跡する場合、操作識別子が”z”で終わるファイルのグループと、操作識別子が上限値の32文字に達したファイルのグループとの2つのグループができる。これらのファイルグループは、ファイル操作履歴のツリー構造において葉の部分となるが、必ずしも不正な操作されたファイルであるとは限らない。
 従って、本実施例では、操作識別子の桁数が32文字に達した場合(3614)と、操作識別子の最後が”z”で終わっている場合(3608)とを、不正操作のための値(状態)とする。不正操作以外の操作の場合は、それぞれの一つ前の状態の操作識別子の桁数が31文字になる状態まで、または、操作識別子に文字”y”が追加される状態まで遷移させる。
 図36は、同一のファイルを何度もコピーした場合のファイル操作履歴のツリー構造を示す。大元のファイル3801をコピーするたびに、コピー先ファイルに関する操作識別子に付与される文字が0, 1, 2・・・と増えていき、やがて上限”y”に達する(3802)。
 それ以降の不正操作でないコピー操作により作成されるファイルの操作識別子には、全て”y”が付与される(3803、3804)。その後、ファイル3801に対して不正操作を行うと、操作識別子に”z”が付与される(3807)。操作識別子に”z”が付与された操作には、子ノードはできない。従って、操作識別子の最後に”z”が設定されている操作は、不正操作であると一見して分かる。
 図37は、操作先ファイルをさらに操作する場合を示す。コピー操作を繰り返すと、操作識別子の桁が増えていき、やがて操作識別子の桁数が31桁の上限に達する(3901)。操作識別子が31桁に達したファイルをさらに操作した場合、操作識別子は更新されない(3902、3903)。操作識別子が31桁に達したファイルグループ(3904)に属するいずれかのファイルが外部に持ち出された場合、その持ち出されたファイルに関する操作識別子に”0”を設定する。これにより、その操作識別子は32桁となり、操作識別子に”z”を付与したときと同様に、ツリー構造の葉となる。従って、ツリー構造を見れば、直ちに不正操作であることが分かる。
 図38は、PC管理DBに記憶された管理情報4001-4008を用いて、ファイル操作の履歴をツリー構造として可視化する様子を示す。まず始めに、ユーザは、PC管理DBに記憶されている各操作のうち、追跡したいファイルを選択する。
 管理サーバ111のマネージャ112は、ユーザにより選択されたファイルのファイル格納識別子を検索キーとしてPC管理DBを検索し、選択されたファイル格納識別子を有するレコードを抽出する。さらに、マネージャ112は、抽出された各レコードを操作識別子に基づいてソートする。並び替えた結果が、図38の上側に示すテーブル4010である。
 テーブル4010の結果は、ツリー構造を深さ優先探索(Depth First
Search)した順を示すため、テーブル4010の結果に基づいて容易にツリー構造4020を描画できる。操作識別子の最後の文字を取り除いたトレース情報が、親のトレース情報となる。例えば、操作識別子が”0010” である操作の親の操作(親の操作とは、それよりも一つ前の操作)は、操作識別子”001”を有する操作となる。ツリー表示画面4020とテーブル4010とにおいて、4001と4011、4002と4012、4003と4013、4004と4014、4005と4015、4006と4016、4007と4017、4008と4018が、それぞれ対応する。
 以上、ファイルシステム204上でのファイル操作を中心に、ファイル操作の履歴監視(ファイル操作トレース)を説明した。しかし、本実施例は、ファイルシステム上でのファイル操作に限定されず、Webブラウザを用いたファイルのアップロードまたはダウンロード、電子メールを利用したファイルの送受信、アプリケーションプログラムからの印刷、のような場合にも適用できる。
 ファイル操作としては、上述したファイルの作成、移動、コピー、名称変更、削除に限定されない。例えば、
(1)Webブラウザを用いたファイルのダウンロード、
(2)Webブラウザを用いたファイルのアップロード、
(3)添付ファイル付き電子メールの受信、
(4)添付ファイルの保存、
(5)添付ファイル付き電子メールの送信、
(6)印刷
を、ファイル操作として管理できる。
 Webブラウザを用いたファイルのアップロードまたはダウンロード等において、操作元ファイルと操作先ファイルの関係は次の通りとなる。ここでは、操作元ファイルを操作元、操作先ファイルを操作先と略す。
(1)Webブラウザでのファイルダウンロード
 (1A)操作元→ダウンロード元のURL(ステップ403、502で取得)
 (1B)操作先→保存先のファイルパス(ステップ406、510で取得)
(2)Webブラウザでのファイルアップロード
 (2A)操作元→アップロードするファイルパス(ステップ807で取得)
 (2B)操作先→アップロード先のURL(ステップ808で取得)
(3)添付ファイル付きメールの受信
 (3A)操作元→送信元のメールアドレス(ステップ604、704の送信者名)
 (3B)操作先→入力元DB393
(4)添付ファイルの保存
 (4A)操作元→入力元DB393
 (4B)操作先→保存先のファイルパス(ステップ609、709で取得)
(5)添付ファイル付きメールの送信
 (5A)操作元→送信するファイルパス(ステップ907、1007で取得)
 (5B)操作先→送信先のメールアドレス(ステップ904、1004の送信者名)
(6)印刷
 (6A)操作元→印刷元のファイルパス(ステップ1105で取得)
 図39は、入力元DB393の構成例を示す。図39では、クライアントPC121が添付ファイル付き電子メールを受信した場合に、その操作元を入力元DB393とすべく、入力元DB393でファイル格納識別子と操作識別子及びカウントを管理できるようにしている。そのために、入力元DB393には、ファイル格納識別子フィールド4101と、操作識別子フィールド4102と、カウントフィールド4103とが追加されている。
 上記各操作(1)-(6)を追跡するために、入力元識別子を付与するステップ(407、511、611、711)と、アラート条件に該当するか否かをチェック等するステップ(809、908、1008、1107)と、入力元DB393に登録するステップ(606、706)とのそれぞれにおいて、図32で述べた処理を実行する。
 図32の処理を実行するにあたり、上記各操作(1)-(6)毎に、以下の点が相違する。
(1)Webブラウザでのファイルダウンロード
 この操作はファイルの起点となる操作であるから、ステップ3401の判定は必ず”Yes”となる。
(2)Webブラウザでのファイルアップロード
 起点となる操作であるため、ステップ3401では”No”と判定される。
 ステップ3415のチェックでは、操作先がURL(外部)となるため、”No”と判定される。
(3)添付ファイル付きメールの受信
 この操作はファイルの起点となる操作であり、ステップ3401の判定では必ず”Yes”となる。
 ステップ3403の処理では操作先が入力元DB393であるため、ファイルの代替ストリームにトレース情報を書き込むのではなく、入力元DB393にインファイルトレース情報を格納する。操作先を入力元DB393にするのは、電子メールに添付されたファイルが複数回ファイルシステム204にコピーされた場合でも、大元の操作(添付ファイル付き電子メールの受信)を特定できるようにするためである。
(4)添付ファイルの保存
 ステップ3401では”No”と判定される。
 ステップ3410では、操作元の代替ストリームからインファイルトレース情報を取得するのではなく、入力元DB393からインファイルトレース情報を取得する。
 ステップ3418も同様に、入力元DB393にインファイルトレース情報を格納する。
(5)添付ファイル付きメールの送信
 ステップ3401では”No”と判定される。
 ステップ3415では、操作先がメールアドレス(外部)のため”No”と判定される。
(6)印刷
 ステップ3401では”No”と判定される。
 ステップ3415では、操作先が紙媒体(外部)のため”No”と判定される。
 以上のように、本実施例は、上記(1)-(6)の操作の履歴も管理できる。図40には、ユーザの選択した条件に従ってPC管理DBから抽出されたテーブル4210と、テーブル4210に基づいて描画されるファイル操作履歴のツリー構造4220とが示されている。
 このように構成される本実施例では、ファイル操作の履歴を効率的に管理することができる。さらに、ファイル格納識別子及び操作識別子を用いることにより、ファイル操作の履歴をツリー構造で簡単に表示することができる。
 ファイル格納識別子及び操作識別子を備えないDBの場合は、操作元ファイルをDBから読み込んだ後、その操作元ファイルで操作先ファイルのフィールドを検索し、検索されたファイル名で操作元ファイルのフィールドを再び検索する等の作業を何度も繰り返す必要がある。従って、DBへのアクセス数が大幅に増加し、操作履歴を抽出したテーブルの作成及びツリー構造の表示に時間がかかる。
 これに対し、本実施例では、ファイル格納識別子と操作識別子をPC管理DBから読み込むだけで、ユーザの選択したファイルの操作履歴を容易に抽出でき、ツリー構造で表示することができる。従って、使い勝手が向上する。
 さらに、本実施例では、ファイルの代替ストリームに、ファイル格納識別子と操作識別子及びカウントを書き込む(さらに、第1実施例で述べたように、代替ストリームに入手元識別子が書き込まれる場合もある)。従って、もしも、PC管理DBが一時的に停止したり、レコードの一部が破損等した場合でも、ファイルの代替ストリームに記憶されているインファイルトレース情報を読み出すことにより、ファイル操作の履歴を管理することができる。
 なお、ファイルの操作の履歴を管理するための情報を、ファイルの代替ストリームに格納するのではなく、クライアントPC内のDBに格納して管理する構成でもよい。例えば、図52に示すような構成のDBを用いて、クライアントPCに入出力されるファイルの操作履歴を監視することもできる。
 また、NTFSの代替ストリームに限らず、例えば、リソースフォークのような、付属データ領域を用いても良い。付属データ領域とは、ファイルに付属するデータ領域であって、ファイルが操作されるとファイルデータと共に操作対象となる領域である。付属データ領域には、ファイルデータに対するリード関数またはライト関数とは別の関数を用いることにより、または、リード関数またはライト関数に通常とは異なる引数を指定することにより、データを読み書きすることができる。
 図41-図51を参照して第3実施例を説明する。第1実施例では、Webブラウザ上のユーザ操作またはダイアログへの入力文字列等を取得することで、URLまたはメールアドレスと、ファイルシステム204上のフルパスとを取得する。本実施例では、他の方法を用いて、ファイルのパス情報(フルパス)とURLまたはメールアドレスとの対応関係を検出する。
 図41は、クライアントPC121の構成を示す。ディスク209には、ファイルシステム204と、システムポリシ391と、セキュリティポリシ392と、ブラウザ入力DB4901と、ブラウザ出力DB4902と、メール入力DB4903と、メール出力DB4904とが格納されている。
 図42は、エージェントプログラム122の構成を示す。本実施例では、プロセス監視モジュール310と、プリンタ監視モジュール320と、ファイルI/O監視モジュール370と、HTTP通信監視モジュール380と、TCP通信監視モジュール360とを備える。
 ファイルI/O監視モジュール370は、Webブラウザ305または各種アプリケーションプログラムで発生したファイル入出力を検知するファイルI/O検知機能371と、ファイルの代替ストリームに入手元情報(入手元識別子)を書き込むための入手元情報付与機能372とを備える。
 HTTP通信監視モジュール380は、ファイルの送受信を検知するソケット受信検知機能381と、ソケット308を介して送受信されたデータを解析するプロトコル解析機能382と、登録と入手元情報の付与及び検査をする機能383とを備える。登録及び通知等を行う機能383は、ソケット308を介してファイルがクライアントPC121にダウンロードされた場合に、そのファイルに入手元情報を付与し、ブラウザ入力DB4901に登録させる。
 TCP通信監視モジュール360とHTTP通信監視モジュール380とは、通信ネットワーク上の通信を監視する。TCP通信監視モジュール360は、メール(POP3・IMAP・SMTP)の送受信を監視する。HTTP通信監視モジュール380は、HTTP通信を監視する。ファイルI/O監視モジュール370は、Webブラウザまたはメーラを用いた、ファイルの読み書きを監視するものである。
 本実施例では、通信ネットワークを介して送受信されたファイルデータと、ファイルシステム204に入出力されたファイルデータとを結びつけるために、それらファイルデータのハッシュ値をキーとするDB4901-4904を設けている。
 ファイルをクライアントPC121にダウンロードする場合を説明する。ユーザがファイルをダウンロードすると、TCP通信監視モジュール360またはHTTP通信監視モジュール380により、ダウンロード元の情報(URLまたはメールアドレス)とダウンロードデータとを取得できる。このダウンロード元の情報とダウンロードされたデータのハッシュ値とを、入力DB(図48、図50参照)に格納する。
 ここで図48を参照する。図48は、ブラウザ入力DB4901の構成例を示す。ブラウザ入力DB4901は、Webブラウザを介してダウンロードされたファイルを管理する。ブラウザ入力DB4901は、例えば、入手元URLフィールド4901Aと、ハッシュ値フィールド4901Bと、ファイル格納識別子フィールド4901Cと、操作識別子フィールド4901Dと、カウントフィールド4901Eとを備える。
 入手元URLフィールド4901Aには、ファイルのダウンロード元のURLが記憶される。ハッシュ値4901Bには、ダウンロードされたファイルのデータから算出されるハッシュ値が記憶される。ファイル格納識別子フィールド4901Cには、ダウンロードされたファイルに付与されるファイル格納識別子が記憶される。操作識別子フィールド4901Dには、ダウンロードされたファイルに設定される操作識別子が記憶される。カウントフィールド4901Eには、ダウンロードされたファイルに関するカウントが記憶される。ハッシュ値、ファイル格納識別子、操作識別子、カウントについては、後述する他のDBも同様である。
 図50を参照する。図50は、メーラを介して取得されるファイル(電子メールに添付されたファイル)を管理するDB4903の例を示す。メール入力DB4903は、例えば、ファイル名フィールド4903Aと、送信者名フィールド4903Bと、ハッシュ値フィールド4903Cと、ファイル格納識別子フィールド4903Dと、操作識別子フィールド4903Eと、カウントフィールド4903Fとを備える。
 ファイル名フィールド4903Aには、電子メールに添付されたファイルの名称が記憶される。送信者名フィールド4903Bには、ファイルの添付された電子メールの送信者名が記憶される。ハッシュ値、ファイル格納識別子、操作識別子及びカウントは、図48と同様であるため説明を省略する。
 ブラウザまたはメーラがファイルをダウンロードすると、クライアントPCのファイルシステム上にダウンロードされたファイルデータが書き込まれる。ファイルI/O監視モジュール370は、ファイルシステム204へのファイルデータの書き込みを検知する。
 ファイルI/O監視モジュール370は、ブラウザまたはメーラが保存したファイルデータのハッシュ値を求め、入力DB4901,4903(図48、図50)に同一ハッシュ値のレコードがあるかを探す。同一のハッシュ値のレコードが存在する場合、そのレコードはダウンロードされたファイルを示している。従って、ハッシュ値により特定されるファイルに、対応する入力元情報やインファイルトレース情報を付与する。
 ファイルをアップロードする場合を説明する。ユーザは、Webブラウザまたは電子メールを用いて、ファイルをクライアントPCの外部に送信することができる。ユーザがファイルをアップロードすると、ブラウザまたはメーラは、アップロード対象のファイルデータを読み込む。ファイルI/O監視モジュール370は、そのファイルデータの読み込みを検知する。ファイルI/O監視モジュール370は、ブラウザまたはメーラが読み込んだファイルの、パス及びハッシュ値を求めて、出力DB4902,4904(図49、図51)に格納する。
 図49を参照する。図49は、ブラウザを用いてクライアントPC121の外部に出力されたファイルを管理するDB4902である。ブラウザ出力DB4902は、例えば、アップロードファイルフィールド4902Aと、ハッシュ値4902Bと、送信元フィールド4902Cと、サーバフィールド4902Dと、URLフィールド4902Eと、ファイル格納識別子フィールド4902Fと、操作識別子フィールド4902Gと、カウントフィールド4902Hとを備える。
 アップロードファイルフィールド4902Aには、アップロードされたファイルのパス情報がアップロードされたファイルの格納先を示すパス情報が記憶される。送信元フィールド4902Cには、ファイルをアップロードしたユーザ名が記憶される。サーバフィールド4902Dには、アップロード先のサーバ名が記憶される。URLフィールド4902Eには、アップロード先のURLが記憶される。
 ブラウザまたはメーラは、ファイルデータを読み込むと、そのファイルデータをアップロードする。TCP通信監視モジュール360またはHTTP通信監視モジュール380は、ファイルのアップロードを検知する。
 TCP通信監視モジュール360またはHTTP通信監視モジュール380は、アップロードされるファイルのデータを取得し、そのハッシュ値を求める。TCP通信監視モジュール360またはHTTP通信監視モジュール380は、求めたハッシュ値と同一のハッシュ値を有するレコードが出力DB4902,4904あるかを検索する。同じハッシュ値のレコードが存在する場合、ユーザがファイルをアップロードしたと判断できる。ファイルがアップロードされたと判断された場合、第1実施例で述べたように、アラート条件に合致するか否かのチェックと、アラートの送信と、インファイルトレース情報の操作等が行われる。
 図43を参照する。図43は、ブラウザを用いてファイルをダウンロードする場合のシーケンスを示す。
 ユーザは、ブラウザを用いてファイルのダウンロードを開始する(5101)。HTTP通信監視モジュールは、HTTP通信のヘッダを検知し、そのヘッダ解析する(5102)。解析の結果、受信操作であれば、ステップ5103以降を実行する。送信操作であれば図44のステップ5212以降を実行する。
 HTTP通信監視モジュールは、ステップ5102の解析結果から入手元URLと入手データ(ダウンロードファイル)とを取得する(5103)。HTTP通信監視モジュールは、ステップ5103で取得した入手データのハッシュ値を計算する(5104)。HTTP通信監視モジュールは、図32に示すインファイルトレース情報の操作を行う(5105)。ここでは、ブラウザでのファイルダウンロードであるため、新規にインファイルトレース情報を作成する。HTTP通信監視モジュールは、入手元URLと、入手データのハッシュ値と、インファイルトレース情報とを、ブラウザ入力DB4901に格納する(5106)。
 ファイルのダウンロードが開始されると、ブラウザは、ソケット308からダウンロードデータを受け取り、ファイルシステム204へダウンロードデータを書き込む(5111)。
 ファイルI/O監視モジュールは、ステップ5111の動作をAPI(Application Programming Interface)フックなどの方法で検知する(5112)。ファイルI/O監視モジュールは、ブラウザがファイルシステム204に書き込んだデータのハッシュ値を求める(5113)。ファイルI/O監視モジュールは、ブラウザによるファイル書込先のパスを取得する(5114)。
 ファイルI/O監視モジュールは、ステップ5113で求めたハッシュ値を検索キーとしてブラウザ入力DB4901を検索する。同一のハッシュ値を有するレコードが見つかった場合、そのレコードで管理されるファイルは、ユーザがダウンロードしたファイルである。そこで、ファイルI/O監視モジュールは、ブラウザ入力DB4901からファイル属性(入手元URL、ファイル操作トレース情報)を取得し、ステップ5116以降を実行する。
 ダウンロードされたファイルのハッシュ値と同一ハッシュ値を有するレコードが見つからない場合、ユーザのダウンロード操作で発生したファイル書き込みではないため、本処理を終了する。
 ファイルI/O監視モジュールは、ハッシュ値に基づいて発見されたファイルの代替ストリームに、入手元情報(図13の1311)を書き込む(5116)。さらに、ファイルI/O監視モジュールは、ファイルの代替ストリームに、インファイルトレース情報(図30の3201)を書き込む(5117)。
 図44は、ブラウザを用いたファイルのアップロード処理を示すシーケンスである。ユーザがブラウザを用いてファイルのアップロードを開始すると(5201)、 ブラウザはアップロード対象のファイルを読み込む(5202)。
 ファイルI/O監視モジュールは、ステップ5202の動作をAPIフックなどの方法で検知する(5203)。ファイルI/O監視モジュールは、ブラウザが読み込んだファイルのハッシュ値を求める(5204)。ファイルI/O監視モジュールは、ファイルの代替ストリームから入手元情報を取得する(5205)。さらに、ファイルI/O監視モジュールは、ファイルの代替ストリームからインファイルトレース情報を取得する(5206)。ファイルI/O監視モジュールは、ファイルのパスと、ファイルのハッシュ値と、入手元情報と、インファイルトレース情報とを、ブラウザ出力DB4902(図49)へ格納させる。
 ブラウザは、アップロードファイルの読込みを完了すると、ソケット308を介してファイルをアップロードする。この送信動作は、HTTP通信監視モジュールにより検知される(5211)。HTTP通信監視モジュールは、HTTPヘッダを解析し(5211)、送信操作であればステップ5212以降を実行する。受信操作であれば、図43の5103以降を実行する。
 HTTP通信監視モジュールは、ステップ5211におけるヘッダ解析結果からアップロード先URLと、アップロードデータとを取得する(5212)。HTTP通信監視モジュールは、ステップ5212で取得したアップロードデータのハッシュ値を計算する(5213)。
 HTTP通信監視モジュールは、ステップ5213で求めたハッシュ値に基づいてブラウザ出力DB4902を検索し、アップロードされたファイルのハッシュ値と同一のハッシュ値を有するレコードを取得する。同一ハッシュ値のレコードが見つかった場合、そのレコードで管理されるファイルは、ユーザによりアップロードされたファイルである。従って、HTTP通信監視モジュールは、そのレコードからファイル属性(ファイルのパス、入手元情報、ファイル操作トレース情報(FID、OID、カウント))を取得し(5214)、ステップ5215以降を実行する。もしも、同一ハッシュ値のレコードが見つからなかった場合、監視対象のブラウザ以外のプログラムによる通信であるため、本処理を終了する。
 HTTP通信監視モジュールは、ハッシュ値に基づいて検出されたファイルについてインファイルトレース情報を操作する(5215)。さらに、HTTP通信監視モジュールは、ブラウザによるファイルのアップロードがアラート条件に合致するか否かをチェックし、必要ならばアラートを送信する(5216)。
 図45は、メーラを用いたファイルの受信と、受信ファイルの保存とに関するシーケンスである。ユーザがメーラを用いてメール受信を開始すると(5301)、TCP通信監視モジュールは、TCP通信のヘッダを検知し、そのヘッダを解析する(5302)。
 解析の結果、受信メールにファイルが添付されている場合はステップ5303以降を実行する。なお、送信されるメールにファイルが添付されている場合は、図44の5412以降を実行する。添付ファイルがないメール送受信の場合、または、メール送受信以外の通信の場合は、本処理を終了する。
 TCP通信監視モジュールは、ステップ5302の解析結果から、メールの送信者名と添付ファイルのファイル名と添付ファイルのデータとを取得する(5303)。続いて、TCP通信監視モジュールは、ステップ5303で取得した添付ファイルのデータのハッシュ値を計算する(5304)。
 TCP通信監視モジュールは、図32に示すインファイルトレース情報の操作を行う(5305)。添付ファイル付きメールを受信した場合であるため、新規にインファイルトレース情報が作成される。TCP通信監視モジュールは、添付ファイル名と、送信者名と、添付ファイルデータのハッシュ値と、インファイルトレース情報とを、メール入力DB4903(図50)へ格納する(5306)。
 ユーザが、メールに添付されたファイルの保存操作を行うと(5310)、メーラは添付ファイルをファイルシステム204に書き込む(5311)。
 ファイルI/O監視モジュールは、ステップ5311の動作をAPIフックなどの方法で検知する(5312)。ファイルI/O監視モジュールは、メーラが書き込んだファイルデータのハッシュ値を求める(5313)。さらに、ファイルI/O監視モジュールは、メーラがファイルを書き込んだ先のパスを取得する(5314)。
 ファイルI/O監視モジュールは、ステップ5313で求めたハッシュ値に基づいて、メール入力DB4903(図50)を検索する。メーラによりファイルシステムに書き込まれたファイルのハッシュ値と同一ハッシュ値のレコードが見つかった場合、そのレコードに対応するファイルは、メールに添付されていたファイルである。そこで、ファイルI/O監視モジュールは、そのレコードからファイル属性(添付ファイル名、送信者名、ファイル操作トレース情報)を取得し(5315)、ステップ5316以降を実行する。
 同一ハッシュ値のレコードが見つからない場合、ステップ5311のファイル書込みは、添付ファイルのダウンロード操作(5310)で発生したファイル書き込みではないため、本処理を終了する。
 ファイルI/O監視モジュールは、インファイルトレース情報の操作を行う(5316)。インファイルトレース情報の操作処理の中で、保存ファイル(メールに添付されていたファイルであって、ファイルシステム204に記憶されたファウル)の代替ストリームに、ファイル操作トレース情報が書き込まれる(5316)。さらに、ファイルI/O監視モジュールは、保存ファイルの代替ストリームに入手元情報(図13の1311)を付与する。
 図46は、メールにファイルを添付して送信する場合のシーケンスを示す。ユーザがメーラを用いてメールへのファイル添付を操作すると(5401)、メーラは、メールに添付するファイルをファイルシステム204から読み込む(5402)。
 ファイルI/O監視モジュールは、ステップ5402でのファイル読込みを、APIフックなどの方法で検知する(5403)。ファイルI/O監視モジュールは、メーラが読み込んだファイルのハッシュ値を求める(5404)。ファイルI/O監視モジュールは、ファイルの代替ストリームから入手元情報を取得する(5405)。ファイルI/O監視モジュールは、ファイルの代替ストリームからインファイルトレース情報を取得する(5406)。ファイルI/O監視モジュールは、ファイルのパスと、ファイルのハッシュ値と、入手元情報と、インファイルトレース情報とを、メール出力DB4904(図51)へ格納する(5407)。
 ユーザが、ファイルを添付したメールを送信させると(5410)、メーラはソケット308を介して、ファイルが添付されたメールを送信する。TCP通信監視モジュールは、そのメール送信を検知し、TCPヘッダを解析する(5411)。ファイルの添付されたメールが送信された場合、ステップ5412以降を実行する。なお、ファイルの添付されたメールを受信した場合は、図45の5303以降を実行する。ファイルの添付されていないメールの送信または受信の場合、あるいは、メール送受信以外の通信の場合は、本処理を終了する。
 TCP通信監視モジュールは、ステップ5411でのヘッダ解析結果から、送信先メールアドレスとメールに添付されたファイルのデータとを取得する(5412)。TCP通信監視モジュールは、ステップ5412で取得したファイルデータのハッシュ値を計算する(5413)。
 TCP通信監視モジュールは、ステップ5413で求めたハッシュ値に基づいて、メール出力DB4904とメール入力DB4903とを検索し、ファイル属性を取得する(5414)。メール出力DB4904とメール入力DB4903とを検索する理由は、後述する。
 TCP通信監視モジュールは、ハッシュ値に基づいて検出されたファイルについて、インファイルトレース情報を操作し(5415)、アラート条件をチェックし、必要があればアラートを送信する(5416)。
 図47は、ファイルの添付されたメールを転送する場合のシーケンスを示す。ファイルの添付されたメールを転送する場合の処理は、図46に示すステップ5410からステップ5416までの処理と同じである。つまり、図47のステップ5510-5516は、図46のステップ5410-5416と同一であるため、説明を省略する。
 図46のステップ5414において、メール出力DB4904とメール入力DB4903の両方を検索する理由を述べる。ユーザがメールにファイルを添付して送信する場合(図46)、メール出力DB4904にレコードが格納される。
 一方、ファイルの添付されたメールが転送された場合(図47)、ユーザは、メール転送の前に、そのメールを受信している(図45)。ファイルの添付されたメールをクライアントPC121のメーラが受信した場合、メール入力DB4903にレコードが格納される。
 TCP通信監視モジュールは、通信を監視しているだけであり、監視している通信が図46に該当する通信(メール送信)なのか、それとも図47に該当する通信(メール転送)なのかを判断できない。そこで、本実施例では、メールの送信か転送かを問わずに、いずれの場合もメール出力DB4904とメール入力DB4903の両方を検索する。
 このように構成される本実施例では、クライアントPCとネットワークとの間の通信を監視し、かつ、ファイルシステムへの入出力を監視する。そして、通信で検出されたファイルのハッシュ値とファイルシステムで管理されているファイルのハッシュ値とを比較することにより、ファイルを特定する。特定されたファイルに入手元情報及びインファイルトレース情報を関連付ける。
 従って、ブラウザを用いたユーザ操作に基づいて、または、ダイアログへ入力された文字列に基づいて、ファイルを特定する構成に比べて、本実施例では、比較的簡単にファイルを特定でき、パス情報またはメールアドレスまたはURLとファイルとを対応付けることができる。
 例えば、ユーザの使用するブラウザの種類が変わったり、または、ブラウザがバージョンアップしたりすることがある。また、アプリケーションプログラムのバージョンアップ等でダイアログの構成が変化したり、全く新しいアプリケーションプログラムがクライアントPC121にインストールされたりする場合もある。それらの環境変化に対応するためには、ブラウザまたはダイアログからパス等を取得するためのコンピュータプログラムをこまめに手直しする必要があり、本システムの維持に手間がかかる。これに対し、本実施例では、通信の監視結果とシステムへの入出力の監視結果とを、共通のハッシュ値で対応付ける。従って、上述のような環境変化の影響を少なくして、本システムを比較的簡単に維持し、運営することができる。なお、本実施例は第1実施例または第2実施例と結合することができる。
 なお、本発明は、上述した実施例に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、第2実施例は、第1実施例と結合することもできるし、第1実施例と独立した構成にもできる。つまり、一つのクライアントPC内で、または、複数のクライアントPCを含むグループ内で、ファイル操作の履歴を管理し、ツリー構造で可視化することができる。
 111…管理サーバ、114…メールサーバ、115…ファイルサーバ、116…組織内Webサーバ、121…クライアントPC、122…エージェントプログラム、123…ネットワークプリンタ123、204…ローカルファイルシステム、310…プロセス監視モジュール、320…プリンタ監視モジュール、330…ブラウザ監視モジュール、340…ダイアログ操作監視モジュール、350…ファイル操作監視モジュール、360…TCP通信監視モジュール、370…ファイルI/O監視モジュール、380…HTTP通信監視モジュール、393…入手元DB、1311…入手元を示す識別子、3201…インファイルトレース情報。

Claims (15)

  1.  ファイルを記憶するクライアントコンピュータと、前記クライアントコンピュータを管理するための管理装置とを含む計算機システムの管理方法であって、
     前記ファイルの操作に関するメタ情報を、前記クライアントコンピュータと前記管理装置の有する管理情報とに記憶し、
     前記ファイルが操作される場合、操作元のファイルに関するメタ情報を前記クライアントコンピュータから取得し、
     前記操作元のファイルに関する前記メタ情報に基づいて、操作先のファイルに関するメタ情報を生成し、
     前記操作先のファイルに関する前記メタ情報を、前記クライアントコンピュータと前記管理情報とに記憶し、
     前記クライアントコンピュータに記憶されている、前記操作元のファイルに関する前記メタ情報を、前記操作元のファイルの操作内容に応じて更新し、
     前記操作元のファイル及び/または前記操作先のファイルの操作履歴を、前記管理情報に基づいて検出し、検出された前記操作履歴を出力させる、
    計算機システムの管理方法。
     
  2.  前記クライアントコンピュータに記憶される前記メタ情報は、前記ファイル内の所定領域に記憶される、
    請求項1に記載の計算機システムの管理方法。
     
  3.  前記メタ情報には、
      前記ファイルが前記クライアントコンピュータの有するファイルシステムに格納される場合に前記ファイルに設定される識別情報であって、前記ファイルを特定するためのファイル格納識別情報と、
      前記ファイルが操作された回数を示す操作世代情報と、
      前記ファイルのコピー回数を示すコピー回数情報と、
    が含まれている、請求項2に記載の計算機システムの管理方法。
     
  4.  前記操作世代情報は、前記操作元のファイルが操作される度に桁数が増加するように構成されており、
     前記操作先のファイルに関する前記メタ情報に含まれる前記操作世代情報は、前記操作元のファイルに関する前記メタ情報に含まれる前記操作世代情報と前記コピー回数情報とに基づいて設定される、
    請求項3に記載の計算機システムの管理方法。
     
  5.  前記操作世代情報の桁数が所定値に達した場合は、前記操作先のファイルの出力先が所定の出力先であると判定されるまでの間、前記操作元のファイルが操作されても前記操作先のファイルに関する前記操作世代情報を更新せず、前記操作先のファイルの出力先が前記所定の出力先であると判定された場合は、前記操作先のファイルに関する前記操作世代情報を更新させる、
    請求項4に記載の計算機システムの管理方法。
     
  6.  前記コピー回数情報の値が他の所定値に達した場合、前記操作先のファイルの出力先が前記所定の出力先であると判定されたときは、前記操作先のファイルに関する前記メタ情報に含まれる前記操作世代情報に所定コードを追加する、
    請求項5に記載の計算機システムの管理方法。
     
  7.  前記操作履歴を検出する場合は、
      前記管理情報の各レコードを前記各ファイル格納識別情報毎にまとめ、
      前記各ファイル格納識別情報毎の前記各レコードを前記操作世代情報に基づいて並び替えることにより、前記操作履歴を検出する、
    請求項6に記載の計算機システムの管理方法。
     
  8.  前記操作履歴をツリー構造で表示出力させる、請求項7に記載の計算機システムの管理方法。
     
  9.  前記計算機システムは、不正操作を検知する不正操作検知システムを含んでおり、
    (1)前記不正操作検知システムは、
     (1-1)前記クライアントコンピュータのマイクロプロセッサを監視対象として、前記監視対象に接続された出力装置の画面上の情報に対する操作を監視する監視装置と、
     (1-2)前記監視装置を管理対象として、前記監視装置の監視結果を管理する管理端末と、を有し、
    (2)前記監視装置は、
     (2-1)前記監視対象に情報を入力するための操作に応答して、前記監視対象に入力される入力情報の入手元を識別するとともに、前記入力情報に、当該入力情報の入手元を示す識別子を付与し、
     (2-2)前記監視対象から情報を出力するための操作に応答して、前記監視対象から出力される出力情報の出力先を識別するとともに、前記出力情報の入手元を示す識別子を検索し、前記識別された出力情報の出力先と前記検索された出力情報の入手元の組み合わせが不正操作の条件に適合するか否かを判定し、この判定結果に従ってアラートを生成するようになっている、
    請求項8に記載の計算機システムの管理方法。
     
  10.  管理装置により管理されるクライアントコンピュータであって、
     前記管理装置は、
      前記クライアントコンピュータと通信するための通信インターフェースと、
      前記クライアントコンピュータを管理するための管理情報と管理プログラムとを記憶するメモリと、
      前記メモリに記憶された前記管理プログラムを読み込んで実行することにより、前記メモリに記憶された前記管理情報に基づいて前記クライアントコンピュータを管理するマイクロプロセッサとを、含んでおり、
     前記クライアントコンピュータは、
      前記管理装置の有する前記通信インターフェースを介して前記管理装置と通信するための他の通信インターフェースと、
      複数のファイルを記憶するファイルシステムと、
      他の管理プログラムを記憶する他のメモリと、
      前記他の管理プログラムを読み込んで実行することにより、前記各ファイルに関するメタ情報を管理する他のマイクロプロセッサとを、含んでおり、
     前記他のマイクロプロセッサは、
     前記ファイルシステムに記憶されるファイルの操作に関するメタ情報を、他の管理情報と前記管理装置の有する前記管理情報とに記憶させ、
     前記ファイルシステムに記憶されるファイルが操作される場合、操作元のファイルに関するメタ情報を、前記他の管理情報から取得し、
     前記操作元のファイルに関する前記メタ情報に基づいて、操作先のファイルに関するメタ情報を生成し、
     前記操作先のファイルに関する前記メタ情報を、前記他の管理情報と前記管理装置の有する前記管理情報とに記憶させ、
     前記他の管理情報に記憶されている、前記操作元のファイルに関する前記メタ情報を、前記操作元のファイルの操作内容に応じて更新させる、
    クライアントコンピュータ。
     
  11.  前記他の管理情報は、前記ファイル内または前記メモリ内のいずれか一方に設けられている、請求項10に記載のクライアントコンピュータ。
     
  12.  前記メタ情報には、
      前記ファイルが前記ファイルシステムに格納される場合に前記ファイルに設定される識別情報であって、前記ファイルを特定するためのファイル格納識別情報と、
      前記ファイルが操作された回数を示す操作世代情報と、
      前記ファイルのコピー回数を示すコピー回数情報と、
    が含まれている、請求項11に記載のクライアントコンピュータ。
     
  13.  前記操作世代情報は、前記操作元のファイルが操作される度に桁数が増加するように構成されており、
     前記操作先のファイルに関する前記メタ情報に含まれる前記操作世代情報は、前記操作元のファイルに関する前記メタ情報に含まれる前記操作世代情報と前記コピー回数情報とに基づいて設定される、
    請求項12に記載のクライアントコンピュータ。
     
  14.  前記操作世代情報の桁数が所定値に達した場合は、前記操作先のファイルの出力先が所定の出力先であると判定されるまでの間、前記操作元のファイルが操作されても前記操作先のファイルに関する前記操作世代情報を更新せず、前記操作先のファイルの出力先が前記所定の出力先であると判定された場合は、前記操作先のファイルに関する前記操作世代情報を更新させる、
    請求項13に記載のクライアントコンピュータ。
     
  15.  前記ファイルシステムに入出力される第1ファイルのデータに基づいて当該第1ファイルを特定するための第1ハッシュ値を生成し、
     前記他の通信インターフェースを介して入出力される第2ファイルのデータに基づいて当該第2ファイルを特定するための第2ハッシュ値を生成し、
     前記第1ハッシュ値と前記第2ハッシュ値とを比較し、
     前記第1ハッシュ値と前記第2ハッシュ値とが一致する場合は、前記第1ファイルと前記第2ファイルが同一であると判定し、前記第1ファイルを示すパス情報を前記第2ファイルに対応付け、さらに、前記第1ファイルに関する前記メタ情報を前記第2ファイルに関連付けるか、あるいは、前記第2ファイルに関する前記メタ情報を前記第1ファイルに関連付けるかのいずれかを実行させる、
    請求項14に記載のクライアントコンピュータ。
PCT/JP2010/061000 2010-04-02 2010-06-28 計算機システムの管理方法及びクライアントコンピュータ WO2012001763A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/934,235 US9124616B2 (en) 2010-04-02 2010-06-28 Computer system management method and client computer
PCT/JP2010/061000 WO2012001763A1 (ja) 2010-06-28 2010-06-28 計算機システムの管理方法及びクライアントコンピュータ
JP2012522369A JP5417533B2 (ja) 2010-06-28 2010-06-28 計算機システムの管理方法及びクライアントコンピュータ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/061000 WO2012001763A1 (ja) 2010-06-28 2010-06-28 計算機システムの管理方法及びクライアントコンピュータ

Publications (1)

Publication Number Publication Date
WO2012001763A1 true WO2012001763A1 (ja) 2012-01-05

Family

ID=45353538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/061000 WO2012001763A1 (ja) 2010-04-02 2010-06-28 計算機システムの管理方法及びクライアントコンピュータ

Country Status (3)

Country Link
US (1) US9124616B2 (ja)
JP (1) JP5417533B2 (ja)
WO (1) WO2012001763A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015176393A (ja) * 2014-03-17 2015-10-05 日本電気株式会社 ストレージ装置、ストレージシステム、ストレージシステムの制御方法および制御プログラム
WO2016072310A1 (ja) * 2014-11-05 2016-05-12 キヤノン電子株式会社 特定装置、その制御方法、及びプログラム
US10318727B2 (en) 2016-03-10 2019-06-11 Fujitsu Limited Management device, management method, and computer-readable recording medium
US10326792B2 (en) 2012-12-07 2019-06-18 Canon Denshi Kabushiki Kaisha Virus intrusion route identification device, virus intrusion route identification method, and program

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5327240B2 (ja) * 2011-01-31 2013-10-30 ブラザー工業株式会社 通信装置および通信装置システム
JP5183770B2 (ja) * 2011-05-20 2013-04-17 キヤノン株式会社 文書管理プログラム、情報処理装置
US20130097122A1 (en) * 2011-10-12 2013-04-18 Jeffrey Liem Temporary File Storage System and Method
US8413236B1 (en) * 2012-06-04 2013-04-02 Robert Hansen Clickjacking protection
EP2796954B1 (de) * 2013-04-23 2015-11-25 Siemens Aktiengesellschaft Numerische Steuerung mit Benachrichtigung eines CAM-Systems bei Änderung des Teileprogramms
JP5737469B1 (ja) * 2014-08-22 2015-06-17 富士ゼロックス株式会社 制御装置およびプログラム
US10225158B1 (en) * 2014-12-22 2019-03-05 EMC IP Holding Company LLC Policy based system management
US9870482B1 (en) 2015-09-30 2018-01-16 Open Text Corporation Method and system for managing and tracking content dissemination in an enterprise
US10671370B2 (en) * 2018-05-30 2020-06-02 Red Hat, Inc. Distributing file system states
JP7031569B2 (ja) * 2018-11-29 2022-03-08 日本電信電話株式会社 情報作成装置、情報作成方法、および、情報作成プログラム
CN113407416B (zh) * 2021-06-29 2022-06-24 杭州默安科技有限公司 一种文件操作ip溯源方法和系统

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08292961A (ja) * 1995-04-20 1996-11-05 Fuji Xerox Co Ltd 文書複写関係管理システム
JPH0944432A (ja) * 1995-05-24 1997-02-14 Fuji Xerox Co Ltd 情報処理方法および情報処理装置
JPH0954735A (ja) * 1995-06-07 1997-02-25 Fuji Xerox Co Ltd 情報処理方法及び情報処理装置
JPH11259459A (ja) * 1998-03-06 1999-09-24 Fuji Xerox Co Ltd 文書管理装置
JP2005189995A (ja) * 2003-12-24 2005-07-14 Hitachi Ltd ファイル授受プロセス管理方法、および、ファイル授受プロセス可視化方法、ならびに、ファイル授受システムにおけるファイル授受プロセス管理装置、および、ユーザ端末
JP2008052570A (ja) * 2006-08-25 2008-03-06 Hitachi Software Eng Co Ltd 操作履歴管理システム
JP2008181446A (ja) * 2007-01-26 2008-08-07 Fuji Xerox Co Ltd 文書管理装置、情報処理装置、文書管理システム及びプログラム
JP2009187374A (ja) * 2008-02-07 2009-08-20 Toshiba Corp 情報ライフサイクル管理システム、情報管理サーバ装置、電子媒体制御装置及びプログラム
JP2010003051A (ja) * 2008-06-19 2010-01-07 Fuji Xerox Co Ltd 文書情報処理装置、及びプログラム
WO2010074094A1 (ja) * 2008-12-26 2010-07-01 株式会社 東芝 情報ライフサイクル管理システム、情報管理サーバ装置、情報媒体制御装置及びプログラム

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6412017B1 (en) * 1996-07-01 2002-06-25 Microsoft Corporation Urgent replication facility
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
US6119208A (en) * 1997-04-18 2000-09-12 Storage Technology Corporation MVS device backup system for a data processor using a data storage subsystem snapshot copy capability
US6067541A (en) * 1997-09-17 2000-05-23 Microsoft Corporation Monitoring document changes in a file system of documents with the document change information stored in a persistent log
JP2003044297A (ja) 2000-11-20 2003-02-14 Humming Heads Inc コンピュータリソースの制御を行なう情報処理方法および装置、情報処理システム及びその制御方法並びに記憶媒体、プログラム
US7062649B2 (en) 2001-01-12 2006-06-13 Hewlett-Packard Development Company, L.P. System and method for categorizing security profile rules within a computer system
JP3927376B2 (ja) 2001-03-27 2007-06-06 日立ソフトウエアエンジニアリング株式会社 データ持ち出し禁止用プログラム
US6996672B2 (en) * 2002-03-26 2006-02-07 Hewlett-Packard Development, L.P. System and method for active-active data replication
US6889231B1 (en) * 2002-08-01 2005-05-03 Oracle International Corporation Asynchronous information sharing system
EP1563402A4 (en) 2002-10-30 2010-11-10 Portauthority Technologies Inc METHOD AND SYSTEM FOR ADMINISTRATING CONFIDENTIAL INFORMATION
US7353533B2 (en) 2002-12-18 2008-04-01 Novell, Inc. Administration of protection of data accessible by a mobile device
JP2004334574A (ja) * 2003-05-08 2004-11-25 Hitachi Ltd ストレージの運用管理プログラム、運用管理方法及び管理計算機
JP2005078612A (ja) * 2003-09-04 2005-03-24 Hitachi Ltd ファイル共有システム及びファイル共有装置間のファイル移行方法
US20050134894A1 (en) 2003-10-31 2005-06-23 Information Handling Services Inc. Remote access printing systems and methods
JP3758661B2 (ja) 2003-11-17 2006-03-22 株式会社インテリジェントウェイブ 不正監視プログラム、不正監視の方法及び不正監視システム
US7730026B2 (en) * 2004-07-01 2010-06-01 Apple Inc. Method and system using reusable state information for synchronization and maintenance of data
US8180743B2 (en) 2004-07-01 2012-05-15 Emc Corporation Information management
US8011003B2 (en) 2005-02-14 2011-08-30 Symantec Corporation Method and apparatus for handling messages containing pre-selected data
JP2006302170A (ja) 2005-04-25 2006-11-02 Hitachi Ltd ログ管理方法及び装置
US7933870B1 (en) * 2005-10-12 2011-04-26 Adobe Systems Incorporated Managing file information
US7778980B2 (en) * 2006-05-24 2010-08-17 International Business Machines Corporation Providing disparate content as a playlist of media files
JP4737762B2 (ja) 2006-06-12 2011-08-03 株式会社日立ソリューションズ 機密情報の管理プログラム
JP2007183911A (ja) 2006-08-17 2007-07-19 Intelligent Wave Inc 不正操作監視プログラム、不正操作監視方法、及び不正操作監視システム
JP4518056B2 (ja) 2006-09-25 2010-08-04 富士ゼロックス株式会社 文書操作認証装置、及びプログラム
US8181036B1 (en) 2006-09-29 2012-05-15 Symantec Corporation Extrusion detection of obfuscated content
US7788235B1 (en) 2006-09-29 2010-08-31 Symantec Corporation Extrusion detection using taint analysis
JP4742010B2 (ja) 2006-10-20 2011-08-10 日立キャピタル株式会社 個人情報ファイルの監視システム
JP2008109380A (ja) 2006-10-25 2008-05-08 Media Exchange Inc 電子メール送受信システム
US7653664B2 (en) * 2006-11-03 2010-01-26 Microsoft Corporation Anchor for database synchronization excluding uncommitted transaction modifications
US7966426B2 (en) * 2006-11-14 2011-06-21 Microsoft Corporation Offline synchronization capability for client application
JP5456462B2 (ja) 2007-04-18 2014-03-26 株式会社日立ソリューションズ 電子メールのフィルタリング手段を備えた機器
JP4058467B1 (ja) 2007-05-17 2008-03-12 クオリティ株式会社 電子メールシステムおよび電子メール送受信プログラム
KR100912870B1 (ko) * 2007-06-12 2009-08-19 삼성전자주식회사 컨텐츠 및 메타데이터의 무결성 보장 시스템 및 방법
JP5179792B2 (ja) 2007-07-13 2013-04-10 株式会社日立システムズ 操作検知システム
WO2009068074A1 (de) * 2007-11-26 2009-06-04 Hyperstone Gmbh VERFAHREN ZUR GLEICHMÄßIGEN NUTZUNG MEHRERER FLASHSPEICHERCHIPS
US8370948B2 (en) 2008-03-19 2013-02-05 Websense, Inc. System and method for analysis of electronic information dissemination events
JP2009237804A (ja) 2008-03-26 2009-10-15 Sky Co Ltd 電子メールシステム
JP5390911B2 (ja) 2008-06-03 2014-01-15 株式会社日立製作所 ファイル管理システム
WO2009147855A1 (ja) 2008-06-03 2009-12-10 株式会社 日立製作所 ファイル管理システム
JP5456425B2 (ja) 2008-10-22 2014-03-26 株式会社日立ソリューションズ コンテンツ認可装置
US8286253B1 (en) 2009-11-23 2012-10-09 Trend Micro Incorporated Data leakage prevention for resource limited device
US8843567B2 (en) 2009-11-30 2014-09-23 International Business Machines Corporation Managing electronic messages
US8832802B2 (en) 2010-02-01 2014-09-09 Protextion Technologies, Llc System for distribution permissions for network communications
US8407341B2 (en) 2010-07-09 2013-03-26 Bank Of America Corporation Monitoring communications
US9158621B2 (en) * 2011-08-29 2015-10-13 Sandisk Technologies Inc. System and method of copying data

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08292961A (ja) * 1995-04-20 1996-11-05 Fuji Xerox Co Ltd 文書複写関係管理システム
JPH0944432A (ja) * 1995-05-24 1997-02-14 Fuji Xerox Co Ltd 情報処理方法および情報処理装置
JPH0954735A (ja) * 1995-06-07 1997-02-25 Fuji Xerox Co Ltd 情報処理方法及び情報処理装置
JPH11259459A (ja) * 1998-03-06 1999-09-24 Fuji Xerox Co Ltd 文書管理装置
JP2005189995A (ja) * 2003-12-24 2005-07-14 Hitachi Ltd ファイル授受プロセス管理方法、および、ファイル授受プロセス可視化方法、ならびに、ファイル授受システムにおけるファイル授受プロセス管理装置、および、ユーザ端末
JP2008052570A (ja) * 2006-08-25 2008-03-06 Hitachi Software Eng Co Ltd 操作履歴管理システム
JP2008181446A (ja) * 2007-01-26 2008-08-07 Fuji Xerox Co Ltd 文書管理装置、情報処理装置、文書管理システム及びプログラム
JP2009187374A (ja) * 2008-02-07 2009-08-20 Toshiba Corp 情報ライフサイクル管理システム、情報管理サーバ装置、電子媒体制御装置及びプログラム
JP2010003051A (ja) * 2008-06-19 2010-01-07 Fuji Xerox Co Ltd 文書情報処理装置、及びプログラム
WO2010074094A1 (ja) * 2008-12-26 2010-07-01 株式会社 東芝 情報ライフサイクル管理システム、情報管理サーバ装置、情報媒体制御装置及びプログラム

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10326792B2 (en) 2012-12-07 2019-06-18 Canon Denshi Kabushiki Kaisha Virus intrusion route identification device, virus intrusion route identification method, and program
JP2015176393A (ja) * 2014-03-17 2015-10-05 日本電気株式会社 ストレージ装置、ストレージシステム、ストレージシステムの制御方法および制御プログラム
WO2016072310A1 (ja) * 2014-11-05 2016-05-12 キヤノン電子株式会社 特定装置、その制御方法、及びプログラム
JPWO2016072310A1 (ja) * 2014-11-05 2017-08-17 キヤノン電子株式会社 特定装置、その制御方法、及びプログラム
US10382477B2 (en) 2014-11-05 2019-08-13 Canon Denshi Kabushiki Kaisha Identification apparatus, control method therefor, and storage medium
US10318727B2 (en) 2016-03-10 2019-06-11 Fujitsu Limited Management device, management method, and computer-readable recording medium

Also Published As

Publication number Publication date
JP5417533B2 (ja) 2014-02-19
US9124616B2 (en) 2015-09-01
US20110320508A1 (en) 2011-12-29
JPWO2012001763A1 (ja) 2013-08-22

Similar Documents

Publication Publication Date Title
JP5417533B2 (ja) 計算機システムの管理方法及びクライアントコンピュータ
US8533850B2 (en) Fraudulent manipulation detection method and computer for detecting fraudulent manipulation
CN102959558B (zh) 用于文档策略实施的系统和方法
JP5396314B2 (ja) 不正操作検知システム及び不正操作検知方法
JP5623537B2 (ja) ポータルのためのユーザ定義のプロファイル・タグ、ルール、および推奨
JP2009116884A (ja) デジタル資産を管理するシステムおよび方法
US20100332550A1 (en) Platform For Configurable Logging Instrumentation
US8706778B2 (en) Methods and systems for an action-based interface for files and other assets
WO2013145125A1 (ja) コンピュータシステム及びセキュリティ管理方法
US10803093B2 (en) Systems and methods for enabling a file management label to persist on a data file
JP2020502699A (ja) コンピュータファイルメタデータの収集および表示を実施するためのアーキテクチャ、方法および装置
US20130007769A1 (en) Tracking File-Centric Events
JP5340563B2 (ja) ダウンロード・ロケーションに基づいてファイルを編成する方法および装置
WO2012111144A1 (ja) 不正操作検知方法、不正操作検知システム及び計算機読み取り可能な非一時的記憶媒体
US11354081B2 (en) Information processing apparatus with concealed information
JP2013175132A (ja) 文書管理サーバ装置、文書管理装置、文書管理システム、及び文書管理プログラム
US20070061276A1 (en) Device and method for registering a plurality of types of information
JP2009265962A (ja) 操作ログ情報管理システム
US11797752B1 (en) Identifying downloadable objects in markup language
KR20120116293A (ko) 문서 등록 관리 장치 및 방법
Martini et al. Detecting and manipulating compressed alternate data streams in a forensics investigation
US20240111601A1 (en) Enhanced migration of objects among computing environments
Easttom et al. Windows File Artifacts: Chuck Easttom, Ph. D., D. Sc.
CN111143848A (zh) 一种记录样本行为及制定病毒规则的系统
Bumgarner et al. Implementing Splunk

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 12934235

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10854060

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012522369

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10854060

Country of ref document: EP

Kind code of ref document: A1