読者です 読者をやめる 読者になる 読者になる

投資家、起業家、企業経営者の話

■IVSウィンターワークショップ2013 Session 5
テーマ: 「人生は挑戦だ!」
(スピーカー)
株式会社ディー・エヌ・エー 顧問 川田尚吾 氏
株式会社gumi 代表取締役社長 國光宏尚 氏
KLab株式会社 代表取締役社長 真田哲弥 氏
ヤフー株式会社 執行役員 小澤隆生 氏
モデレーター)
インフィニティ・ベンチャーズLLP 共同代表パートナー 小野裕史 
vimeo.com

■べンチャー・キャピタル進化論~経営者と投資家の付き合い方
川田尚吾氏
松山太河氏
赤浦徹氏
渡辺洋行氏
G1ベンチャー2015
www.youtube.com

プロフェッショナル 仕事の流儀
ベンチャー企業経営者 南場智子の仕事 仕事でこそ、人は育つ」
www.youtube.com

広告を非表示にする

Elasticsearch Reference [5.0] » Getting Started

Elasticsearchのサイトにある最新ドキュメントを少し読んでみる。
まずは「はじめに」のところ。

Getting Started | Elasticsearch Reference [5.0] | Elastic

Getting Started


Elasticsearch is a highly scalable open-source full-text search and analytics engine. It allows you to store, search, and analyze big volumes of data quickly and in near real time. It is generally used as the underlying engine/technology that powers applications that have complex search features and requirements.

Here are a few sample use-cases that Elasticsearch could be used for:


・You run an online web store where you allow your customers to search for products that you sell. In this case, you can use Elasticsearch to store your entire product catalog and inventory and provide search and autocomplete suggestions for them.


・You want to collect log or transaction data and you want to analyze and mine this data to look for trends, statistics, summarizations, or anomalies. In this case, you can use Logstash (part of the Elasticsearch/Logstash/Kibana stack) to collect, aggregate, and parse your data, and then have Logstash feed this data into Elasticsearch. Once the data is in Elasticsearch, you can run searches and aggregations to mine any information that is of interest to you.


・You run a price alerting platform which allows price-savvy customers to specify a rule like "I am interested in buying a specific electronic gadget and I want to be notified if the price of gadget falls below $X from any vendor within the next month". In this case you can scrape vendor prices, push them into Elasticsearch and use its reverse-search (Percolator) capability to match price movements against customer queries and eventually push the alerts out to the customer once matches are found.


・You have analytics/business-intelligence needs and want to quickly investigate, analyze, visualize, and ask ad-hoc questions on a lot of data (think millions or billions of records). In this case, you can use Elasticsearch to store your data and then use Kibana (part of the Elasticsearch/Logstash/Kibana stack) to build custom dashboards that can visualize aspects of your data that are important to you.
Additionally, you can use the Elasticsearch aggregations functionality to perform complex business intelligence queries against your data.


For the rest of this tutorial, I will guide you through the process of getting Elasticsearch up and running, taking a peek inside it, and performing basic operations like indexing, searching, and modifying your data. At the end of this tutorial, you should have a good idea of what Elasticsearch is, how it works, and hopefully be inspired to see how you can use it to either build sophisticated search applications or to mine intelligence from your data.

はじめに

Elasticsearchは、拡張性の高いオープンソース全文検索及び分析エンジンです。
高速かつリアルタイムに大量データの格納、検索、分析を可能にします。
複雑な検索機能要件を持つアプリケーションを動かす基本的なエンジン/技術として一般的に使用されます。

Elasticsearchの使用例は以下の通り。

・オンラインショップ
 販売する全製品のカタログ、在庫情報を格納して、
 製品の検索や入力補完(オートコンプリート)機能を提供することができます。

・価格を通知するプラットフォーム
 例えば、ある電子機器の購入を検討している顧客(買い物上手)が、
 「来月までに、その電子機器の価格が、他のベンダーの価格よりも$x下がったら通知してほしい」
 といった条件を指定して、
 ベンダーの価格をスクレイピングして、Elasticsearchにストアして、
 「その価格の動きと顧客が指定した条件を比較して、条件と一致したら、自動的に顧客に通知する」
 (パーコレーター)といった機能を提供することができます。

・ログデータまたはトランザクションデータを収集して、
 傾向、統計、要約の解析、または異常を解析したい場合には、
 Logstash(Elasticsearch / Logstash / Kibanaスタックの一部)を使用して
 データを収集、集計、解析することができます。
 その後、Logstashを使用して、このデータをElasticsearchへ投入させることができます。
 Elasticsearcにデータが投入された状態になると、
 あなたの関心のある情報の検索や集計を行うことができます。

・定型・非定型検索ソリューション(BI:Business Intelligence)のニーズがあり、
 多くのデータ(数百万、数十億)を迅速に調査し、分析し、視覚化し、
 アドホックな質問(日常的なものに対して、臨時的・専門的な質問)をしたいと考えている、
 といった場合には、Elasticsearchを使用してデータを保存し、
 Kibana(Elasticsearch / Logstash / Kibanaスタックの一部)を使用して、
 重要なデータの側面を可視化できるカスタムダッシュボードを構築できます。
 さらに、Elasticsearchの集計機能を使用して、
 データに対してビジネスインテリジェンス クエリを実行することもできます。

 ⇒データを集計、可視化したり、その集計データを抽出したりして、
  経営上の意思決定にElasticsearch、Kibanaを活用することができます、
  といったことが書いてあるのだろう。
 ※「ビジネスインテリジェンス」- Wikipedia参照
  経営・会計・情報処理などの用語で、企業などの組織のデータを、
  収集・蓄積・分析・報告することで、経営上などの意思決定に役立てる手法や技術のこと。

このチュートリアルでは、Elasticsearchを起動させて、その内部を見ていき、
データの索引付け、検索、変更などの基本的な操作方法を説明いたします。
最後までチュートリアルを読んで頂ければ、Elasticsearchがどのようなものなのか、
洗練された検索アプリケーションを構築するために、また、データマイニングのために、
どのようにElasticsearchを使用できるのかが分かるようになるはずです。

※「データマイニング」とは
 データの集合の中から、知識を発見しよう!というものです。

データマイニング」 - Wikipedia

定義
 データマイニングの定義としては、「明示されておらず今まで知られていなかったが、役立つ可能性があり、かつ、自明でない情報をデータから抽出すること」[1]、「データの巨大集合やデータベースから有用な情報を抽出する技術体系」[2]などがある。 データマイニングは、通常はデータの解析に関する用語として用いられるが、人工知能という用語などと同様、包括的な用語であり、様々な文脈において多様な意味で用いられる。

広告を非表示にする

開発コードネーム 『Beck』 その3

仕様を追加。

多くの人たちのノウハウが1つの場所に集まり、残り続けて、それらが活用され、
また、可能であれば発展させていこうとする流れを作り、
後からプロジェクトに参加する人たちや、
周りの人たちを助けることになるものは何か?と考えている。

その1つはプロジェクト内の各業務での「チェックリスト(確認リスト)」だと思われる。

人によって意図的にさじ加減を変えて、
他人が出した成果物に対して、後出しで、
利点と欠点の両方があるものを、偉そうに欠点のみをあげつらって、
「おまえのためを思って指導してるんだよ」等、
恩着せがましくデカい声で、朝からお説教してるような自己中が威張り腐ってるよりも、
ささやかに、周りの人たちのために「チェックリスト」が作られていたほうが
よっぽどありがたい。

チェックリストを作成して、共有して、
チェックリストに対してPDCAサイクルを回そう!みたいな
仕事の仕方が流行っていくことを狙おうと思う。
真っ当な仕事の仕方だと思われる。

チェックリストの内容をきつくすれば、
品質が良くなりやすいメリットもあれば、仕事にかける時間が長くなるデメリットもある、
チェックリストの内容を軽くすれば、
品質が落ちやすくなるデメリットもあれば、仕事にかける時間が短くなるメリットもある
納期等、時間の制約がある中で、まあ、いろいろと状況が変わる中で、
バランスを取りながら、加減を測りながら、
とにかく、最低限やっておけばいいことは明確にしていけるし、
その時に最適な水準をプロジェクトマネージャーあたりが監視して
探していけばいいさ。

「お客さんと対等に仕事を行う」ためにやっておかなければいけない事が
チェックリストになっていれば、良い場面もある。すべてではないとは思うが。
お客さんの言いなりになり、まるで奴隷になり、プロジェクトが「ドM養成所」になり、
「損」をさせられてしまうことを回避するため。

お客様との打ち合わせに関する業務では・・・
<チェックリスト(例)>
・お客様との打ち合わせの際、○○を伝えて、合意が得られているか?
・お客様に打ち合わせを依頼するメールには○○が記載されているか?
・打ち合わせにおける決定権を持つ人が誰なのか?が明記されている返信をもらっているか?
・打ち合わせを依頼する際、決定権がある人に同席して頂くことを条件として依頼しているか?

みたいな感じのやつ。
もちろん上記だけで十分ではないです。
そのときの状況によって、やるべきことは変わるとも思えますが、
実際に上記のような内容のチェックリストは世の中に存在する。

他には、レビュー時の観点なども、チェックリストになっているとよいし。
(本日2回目)人によって意図的にさじ加減を変えて、
他人が出した成果物に対して、後出しで、偉そうに欠点をあげつらって、
「おまえのためを思って指導してるんだよ」「おまえは相手の事を考えていないんだよ」等、
恩着せがましくデカい声で、威張り腐ってる自己中じじいがお説教してるようなレビューは、
全員で一丸となって行わせないようにしよう、「じじい、しゃしゃり出るな」。
たいしたことない、でしゃばり自己中に後出しのお説教させて、
おだてて、「おれが指導したんだぜ」等、良い気分にさせてるくらいなら、
しれっと黙って、チェックリストを作れ!チェックリストに全員のノウハウを詰め込め!
という流れができればいい。
チェックリストを作るというささやかながらの行動は、
相手や自分たちのこと、後からプロジェクトに参加する人のことも、
お客さんのことも考慮された行動だ。

まあ、プロジェクト内の業務はいろいろだ。
チェックリストもいろいろ出てくるだろう。

対応事例検索機能においては、
プロジェクト内の各業務で使用する「チェックリスト」の登録、検索は、
特別に標準機能にする。この仕様は決定。

広告を非表示にする

SQL Server 2016 データ暗号化

SQL Server 2016 の新機能「Always Encrypted」。
Always Encrypted (Database Engine) (Always Encrypted (データベース エンジン))

以下サイトで、どんなものか確認してみる。
SQL Server 2016 CTP 2.0 の Always Encrypted を使ってみる at SE の雑記

ということらしい。「Always Encrypted」の動作については、また後ほど確認してみるとして。

今のところは、いろいろと検討した結果、管理者側の機能としては、
顧客の「システム担当」が、対称キー作成時のパスワードを
ユーザー情報の登録/更新/参照の際(対称キーOpenの際)に入力した時に、
 ・ユーザー情報を暗号化して登録(更新)できる
 ・ユーザー情報を復号化して参照できる
といった動作にしていくことを予定。
なので「Always Encrypted」を使用しない方法でやってみる。

【1】対称キーの作成(アルゴリズムは AES_256 を指定)
CREATE SYMMETRIC KEY Beck_Sym_Key
WITH ALGORITHM = AES_256
ENCRYPTION BY PASSWORD = '[SymKeyPassword]'
go

f:id:masawan-guitar:20161011003133p:plain

【2】登録時の操作(暗号化)

(例)MST_USERテーブル(CREATE文)

暗号化する項目は[varbinary](max)型。

CREATE TABLE [dbo].[MST_USER](
	[SystemUserID] [uniqueidentifier] NOT NULL,
	[UserID] [varbinary](max) NOT NULL,
	[LoginID] [varbinary](max) NOT NULL,
	[Password] [varbinary](max) NOT NULL,
	[LastName] [varbinary](max) NOT NULL,
	[FirstName] [varbinary](max) NOT NULL,
	[LastNameKana] [varbinary](max) NOT NULL,
	[FirstNameKana] [varbinary](max) NOT NULL,
	[MailAddress1] [varbinary](max) NOT NULL,
	[MailAddress2] [varbinary](max) NULL,
 CONSTRAINT [PK_MST_USER] PRIMARY KEY CLUSTERED 
(
	[SystemUserID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

(1)対称キーをオープンする。対称キーの GUID を Key_GUID 関数で取得して、
 EncryptByKeyでデータを暗号化して INSERT する。

OPEN SYMMETRIC KEY Beck_Sym_Key
DECRYPTION BY PASSWORD = '[SymKeyPassword]'
go

DECLARE @kGuid UNIQUEIDENTIFIER
SET @kGuid = Key_GUID('Beck_Sym_Key')

INSERT INTO MST_USER (
    [SystemUserID],
    [UserID],
    [LoginID],
    [Password],
    [LastName],
    [FirstName],
    [LastNameKana],
    [FirstNameKana],
    [MailAddress1],
    [MailAddress2]
)VALUES(
    NEWID(),
    EncryptByKey(@kGuid, "[UserID]",
    EncryptByKey(@kGuid, "[LoginID]",
    EncryptByKey(@kGuid, "[Password]",
    EncryptByKey(@kGuid, "[LastName]",
    EncryptByKey(@kGuid, "[FirstName]",
    EncryptByKey(@kGuid, "[LastNameKana]",
    EncryptByKey(@kGuid, "[FirstNameKana]",
    EncryptByKey(@kGuid, "[MailAddress1]",
    EncryptByKey(@kGuid, "[MailAddress2]" 
)

(2)対称キーの CLOSE

CLOSE SYMMETRIC KEY Beck_Sym_Key
go

(参考)SELECT文を実行するとデータが暗号化されていることを確認できる。

SELECT * FROM MST_USER

f:id:masawan-guitar:20161010214334p:plain

【3】参照時の操作(復号化)

(1)SELECT文を実行(DecryptByKey で復号化)

対称キーをOPENして、SELECT文を実行。DecryptByKeyでデータを復号化する。

OPEN SYMMETRIC KEY Beck_Sym_Key
DECRYPTION BY PASSWORD = '[SymKeyPassword]'

SELECT TOP 1000 [SystemUserID]
    ,CONVERT(varchar, DecryptByKey([UserID])) AS  [UserID]
    ,CONVERT(varchar, DecryptByKey([LoginID])) AS [LoginID]
    ,CONVERT(varchar, DecryptByKey([Password])) AS [Password]
    ,CONVERT(varchar, DecryptByKey([LastName])) AS [LastName]
    ,CONVERT(varchar, DecryptByKey([FirstName])) AS [FirstName]
    ,CONVERT(varchar, DecryptByKey([LastNameKana])) AS [LastNameKana]
    ,CONVERT(varchar, DecryptByKey([FirstNameKana])) AS [FirstNameKana]
    ,CONVERT(varchar, DecryptByKey([MailAddress1])) AS  [MailAddress1]
    ,CONVERT(varchar, DecryptByKey([MailAddress2])) AS [MailAddress2]
FROM [ProjectManagementSystem].[dbo].[MST_USER]

(2)対称キーの CLOSE

CLOSE SYMMETRIC KEY Beck_Sym_Key

(参考)SELECT文を実行して復号化されたデータを参照。
f:id:masawan-guitar:20161010213804p:plain

※対称キーをDROPする場合

DROP SYMMETRIC KEY Beck_Sym_Key
【4】ユーザ登録を行うプロシージャのサンプル
CREATE PROCEDURE [dbo].[RegistUser]
    @SymKeyPassword varchar(250),
    @UserID varchar(250),
    @LoginID varchar(250) ,
    @Password varchar(max) ,
    @LastName varchar(max) ,
    @FirstName varchar(max) ,
    @LastNameKana varchar(max) ,
    @FirstNameKana varchar(max) ,
    @MailAddress1 varchar(max),
    @MailAddress2 varchar(max)
AS
BEGIN

    DECLARE @OpenCmd nvarchar(MAX)
    SET @OpenCmd =N'OPEN SYMMETRIC KEY Beck_Sym_Key DECRYPTION BY PASSWORD = ''' + @SymKeyPassword + ''' '
    EXECUTE sp_ExecuteSql @OpenCmd

    DECLARE @kGuid UNIQUEIDENTIFIER
    SET @kGuid = Key_GUID('Beck_Sym_Key')

    INSERT INTO MST_USER (
        [SystemUserID],
        [UserID],
        [LoginID],
        [Password],
        [LastName],
        [FirstName],
        [LastNameKana],
        [FirstNameKana],
        [MailAddress1],
        [MailAddress2]
    )VALUES(
        NEWID(),
        EncryptByKey(@kGuid, @UserID),
        EncryptByKey(@kGuid, @LoginID),
        EncryptByKey(@kGuid, @Password),
        EncryptByKey(@kGuid, @LastName),
        EncryptByKey(@kGuid, @FirstName),
        EncryptByKey(@kGuid, @LastNameKana),
        EncryptByKey(@kGuid, @FirstNameKana),
        EncryptByKey(@kGuid, @MailAddress1),
        EncryptByKey(@kGuid, @MailAddress2) 
    )

    CLOSE SYMMETRIC KEY Beck_Sym_Key

END
広告を非表示にする

開発コードネーム 『Beck』 その2

(注)以下は、例えば物理的に隔離された高価なセキュリティールームを用意することができない、
検証環境が無い、その他いろいろ、そもそも「そんなにお金をかけれない」といった状況で
「ソフトウェアの機能+少々の運用ルール」のみで個人情報の保護を実現する方法を
できる限り考えているだけです。世の中はお金持ちばかりでは無いので。
私の居る現場では、個人情報保護のため、特別な権限を持った人のみが入れるセキュリティルームがあります。
でも、そんな環境はどこの現場でも用意できるものではないと思い、
現場で、特別な権限を持たないような人であっても、別の部屋を用意しなくても、
個人情報漏洩の責任を負わされることを気にすることなく仕事が行える状態になり、
また、個人情報の保護、漏洩の防止を実現できる方法は無いか?と試しに考えてみたまでです。
 

「(1)システム管理者側の機能を贅沢にする」について。

個人情報の保護を考慮して、システムの障害原因調査やシステム動作の解析が行える設計としたい。

「ユーザーの個人情報」を「架空の個人情報(実在しない個人情報)」に置き換えたデータを使用して、
システム障害の原因調査が行えるような機能を盛り込むことにする。

今、要件を想像中で、っていうか言われたこと無いけど、そういう感じの要件あるだろう。
システム動作についてデータ調査を依頼したい状況の場合、
調査依頼先が、システムの開発元や保守・運用担当などであったとしても、
「本番環境における個人情報に関するデータを見られたくない」なんていう要望も少なからず、あるはずだ。

そんなご要望にお応えして、
「ご安心ください、個人情報は見えません。『架空の個人情報』が見える状態でデータ調査が可能なんです。」
といったような状況を実現するためのシステムの仕様、取り決め事などを考えている。
そんで軽く運用のイメージを描いてるところだ。詳細は後でまとめるとして。

まずは概要から。

一応の前提(システムの利用権限に関する決め事など)
・システム導入先の組織をA社とする。
・本番運用にて、ユーザー登録時に個人情報は暗号化してDBに登録する仕組みとする。
・暗号キーに関する情報(データ暗号化/復号化の際に使用するパスワード等)を保管するのはA社のみ。
 開発元はA社のその情報を破棄する。
システム開発担当の人たち(ソースが見れる人たち)に対しても
 システム本番運用時のA社固有の暗号キーに関する情報を秘密にしておく。
・本番運用時の個人情報が含まれたデータを「システム開発元(調査を行う側)」は取得することはできない。
・A社のユーザー本人は、自身のユーザーIDが分かる状態。
・ユーザーIDに該当する人が本当は誰なのか?が分かる権限を持つのはA社の「システム担当者」のみ。
・「システム開発元(調査を行う側)」の権限では、A社の本番環境のログインユーザー情報と
 ログインパスワードを知ることはできない。
・「システム開発元(調査を行う側)」の権限で、調査用DBを使用した場合には、
 ログインパスワードを知らなくても「ユーザーID」のみでログイン可能。
f:id:masawan-guitar:20161008195039p:plain

だいたい上記みたいな感じで運用させてみたい、ということだ。

例えば「給与の情報とか、データベースを覗いたら丸裸!」みたいなシステムよりはマシだとは思える。
開発元や保守・運用の人などに対しても、名前を見せないようにすることくらいしたほうがよいと思う。
AES暗号化はエチケット(礼儀作法)のようなものだ。システムにデリカシーは必要だ。
「AES-256」にしようかな。

@IT マスターIT/暗号技術:第3回 AES暗号化
http://www.atmarkit.co.jp/ait/articles/1506/18/news019.html

Microsoft Developer Network(MSDN)
SQL Server 2016 暗号化アルゴリズムの選択」
 https://msdn.microsoft.com/ja-jp/library/ms345262.aspx
「CREATE SYMMETRIC KEY (Transact-SQL)」
 https://msdn.microsoft.com/ja-jp/library/ms188357.aspx

システム動作の解析や、障害の原因調査のような業務では、
個人が誰であるかを特定できない性質の「個人を意味するシステム上のユニークなキー」の情報は必要。
個人が誰であるかを推測し難くするためには「ユニークなキー」は定期的に振り直した方がよいのかな。
まあ、その「ユニークなキー」を本番運用環境DBと調査用DBで一致させるようにする。
→ データベースが自動作成した「uniqueidentifier」型の識別子を利用する。

広告を非表示にする