2018/02/23 Security JAWS 【第8回】参加レポート
Security JAWSの参加レポートです。
s-jaws.doorkeeper.jp
ブログの会社の人のレポートが良くまとまっています。もはや自分でレポート書く意味はあるのだろうか。。
dev.classmethod.jp
Session1:Amazon Web Service Japan 桐山 隼人さん, 塚田 朗弘さん 「 AWS FinTech リファレンス•アーキテクチャーで大手金融機関ばりのセキュリティを実現しよう(仮) 」
情報盛りだくさん。スライド公開希望。
AWS finetec リファレンスガイド、リファレンスアーキテクチャhttps://t.co/cjMqscktiA #secjaws
— 山野 健太 (@yamano3201) 2018年2月23日
- サンプルケース
git-secretshttps://t.co/RRsmOQEbYo
— 山野 健太 (@yamano3201) 2018年2月23日
#secjaws
Session2:CloudNative Inc. 吉田 浩和さん「踏み台環境におけるAmazon Maice活用の提案(仮)」
- 踏み台
- 誰がログインできるか(認証認可)
- 唯一の通り道
- ユーザーの行動記録やデータが通過(監査ポイント)
- 20 CISを参考
- CIS Controls ←後で読む
- 6. Maintenance, Monitoring, and Analysis of Audit Logs
- 13. Data Protection
- 打鍵ログの取得/分析は大事だけど、監査しないと意味はない。
- Amazon Macie
- S3に打鍵ログを保存してMacieで分析する
- バケット設定時とputされたときに評価する
Macie。バージニアとオレゴンだけなのがなぁ。 #secjaws
— 山野 健太 (@yamano3201) 2018年2月23日
Session3:ヴイエムウェア株式会社 大久 光崇さん 「VMware Cloud on AWS ご紹介 - セキュリティ風味」
VMware Cloud on AWS。IPアドレスそのままVMをAWSに持っていける #secjaws
— 山野 健太 (@yamano3201) 2018年2月23日
Session4:Splunk Services Japan 横田 聡さん「事例に学ぶ、Splunk×AWSセキュリティモニタリングの具体策(仮)」
www.slideshare.net
- 何ができるの?
- 横串サーチ
- 原因調査
- アノマリ検知
- 事故例
- アクセスキー悪用
- S3の設定不備
- AWS環境可視化の第一歩
- splunk app
- splunk add on
バケット名は推測が容易な名前を使いがち。
— 山野 健太 (@yamano3201) 2018年2月23日
推奨対策:
・アクセス制御の強化
・CloudTrail操作ログの取得
・データ暗号化(資産の重要度に応じて)
#secjaws
デブサミ2018 2日目 参加レポート
デブサミ2018に参加したのでメモを残しておきます。
Developers Summit 2018
中身は資料を見るのが速いと思うので、講演資料のまとめリンクを置いておきます。
codezine.jp
1日目の参加レポート
yamano3201.hatenablog.jp
- 【16-D-1】IoTサービスを始める際に必要なこととは(松下 享平 [ソラコム]/沖 光芳 [IT工房Z]/高橋 一貴 [チカク])
- 【16-D-2】NRIの働き方改革 - 開発スタイルから文化まで変えた軌跡 -(中川 直樹 [野村総合研究所]/新村 剛史 [アトラシアン])
- 【16-A-3】エンタープライズアジャイル(川口 恭伸 [楽天])
- 【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発(小泉 清一 [デンソー]/佐藤 義永 [デンソー])
- 【16-B-5】1 to 100:子どものためのオープンソースコミュニティ「CoderDojo」が全国100ヶ所を超えるまで(安川 要平 [CoderDojo Japan])
- 【16-A-6】クラウド時代の組織変革の道(各務 茂雄 [ドワンゴ])
【16-D-1】IoTサービスを始める際に必要なこととは(松下 享平 [ソラコム]/沖 光芳 [IT工房Z]/高橋 一貴 [チカク])
www.slideshare.net
IoTで必要なスキル。射撃しつつ前進、トータル力、はんだづけ(オプション) #devsumiD
— 山野 健太 (@yamano3201) 2018年2月16日
【16-D-2】NRIの働き方改革 - 開発スタイルから文化まで変えた軌跡 -(中川 直樹 [野村総合研究所]/新村 剛史 [アトラシアン])
NRIの働き方改革のお話。ツールを通じてチームを変えていくという内容でした。
メールが減った、議論が増えたなどのツール導入による効果測定が難しいものを測定していたのが素晴らしかった。
また、社内で導入した製品やプラグインを社外向けに販売しているという流れも素晴らしかった。
ツール布教で苦労した点3つ。 反対勢力、使い方がわからない、現行保証 #devsumiD
— 山野 健太 (@yamano3201) 2018年2月16日
導入促進のために意識することメモ。
【16-A-3】エンタープライズアジャイル(川口 恭伸 [楽天])
- 作者: Mario E. Moreira,川口恭伸,角征典
- 出版社/メーカー: 翔泳社
- 発売日: 2018/03/19
- メディア: 大型本
- この商品を含むブログを見る
耳の痛い話が多かった。早くアジャイルなエンタープライズにならなければ。
2009年。https://t.co/AsQPlXyBOh #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
顧客価値駆動企業になる #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
計画したから出す。ではなく、お客さんが本当に欲しいかを考える #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
不確実性を懸命な出発点と見なし、偽りや傲慢の確実性を排除する。プロジェクトは順調です。をやめましょう #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
明日解決できるものはありますか? #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発(小泉 清一 [デンソー]/佐藤 義永 [デンソー])
www.slideshare.net
元NECと元東芝の人の話。タイトルは大げさだけど、内容は大きな会社で確実にアジャイルをやっているという話で面白かった。
上司に伺わなければ進めないなどの決定権を取り除くのが鍵、偉い人をいかに突き崩して、意思決定の速いフラットな組織を作るかが大事。
これまた耳が痛い。
アジャイルではリソースを固定すらべき。やっぱり組織変更多いと難しいよなぁ #devsumiE
— 山野 健太 (@yamano3201) 2018年2月16日
— 山野 健太 (@yamano3201) 2018年2月16日
なるべく人を変えないのが重要 #devsumiE
— 山野 健太 (@yamano3201) 2018年2月16日
完成しているチームを二つに割るのはアンチパターン #devsumiE
— 山野 健太 (@yamano3201) 2018年2月16日
【16-B-5】1 to 100:子どものためのオープンソースコミュニティ「CoderDojo」が全国100ヶ所を超えるまで(安川 要平 [CoderDojo Japan])
いつか参加してみたい。
coder dojo 最寄駅でもやってるな #devsumiB
— 山野 健太 (@yamano3201) 2018年2月16日
合意を積み重ねて前に進む #devsumiB
— 山野 健太 (@yamano3201) 2018年2月16日
【16-A-6】クラウド時代の組織変革の道(各務 茂雄 [ドワンゴ])
組織の問題にロジカルな解決策を取っていて参考になった。
- 会社に足りないものは?
- 変革のゴール
- 先行指標(サービス化、エンジニアのレベルアップと良いチーム作り、仕組化)
- 遅行指標(新サービスリリース、売上UP、コストダウン)
- 先行指標を徹底的に磨き上げる
- ドワンゴが実施している内容
イノベーションとガバナンスのトレードオフのマネージメントが肝となる #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
— 山野 健太 (@yamano3201) 2018年2月16日
先行指標を磨き上げる。サービス化、エンジニアのレベルアップと良いチーム作り、仕組み化をちゃんとやる #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
育成は大事 #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
ある程度の制約条件があるということは最大の自由 #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
topから担当者まで同じゴールを持つ #devsumiA
— 山野 健太 (@yamano3201) 2018年2月16日
デブサミ2018 1日目 参加レポート
デブサミ2018に参加したのでメモを残しておきます。
Developers Summit 2018
中身は資料を見るのが速いと思うので、講演資料のまとめリンクを置いておきます。
codezine.jp
- 【15-G-1】AWSのフルマネージドな環境でCI/CDをやってみよう!AWS Cloud9からAWS Fargateへの継続的デプロイをご紹介。(福井 厚[アマゾン ウェブ サービス ジャパン])
- 【15-E-2】Googleのネットワーク開発に見るITエンジニアリングの本質(中井 悦司 [Google Cloud Japan])
- 【15-D-L】サイボウズのリモート開発 変わったもの×変わらなかったもの(水戸 将弥 [サイボウズ])
- 【15-G-4】Machine Learning on AWS(桶谷 拓也 [アマゾン ウェブ サービス ジャパン])
- 【15-D-4】Amazon Alexa Skills開発におけるAWSとの連携(亀田 治伸 [アマゾン ウェブサービス ジャパン])
- 【15-A-6】次世代配車アプリ「タクベル」のシステムアーキテクチャー(小林 篤 [ディー・エヌ・エー])
【15-G-1】AWSのフルマネージドな環境でCI/CDをやってみよう!AWS Cloud9からAWS Fargateへの継続的デプロイをご紹介。(福井 厚[アマゾン ウェブ サービス ジャパン])
codeシリーズを使って開発からコンテナのデプロイするまでのお話。
cloud9はブラウザのみで開発できるIDE。以下は過去記事。
yamano3201.hatenablog.jp
code starでまとめると便利そうなので近いうちに触ってみたいと思います。
新しく知ったことをメモ。
- code starとcloud9が統合された
- code pipelineがFargateのデプロイをサポートしている
cloud formationなしでfargateを直接デプロイできるようになった #devsumiG
— 山野 健太 (@yamano3201) 2018年2月15日
【15-E-2】Googleのネットワーク開発に見るITエンジニアリングの本質(中井 悦司 [Google Cloud Japan])
GCPの裏側の話がメイン。
日本のGCPのソリューションアーキテクトは2名 #devsumiE
— 山野 健太 (@yamano3201) 2018年2月15日
打ち間違えた。成功したもの/完成したものは、もはや古いもの #devsumiE
— 山野 健太 (@yamano3201) 2018年2月15日
【15-D-L】サイボウズのリモート開発 変わったもの×変わらなかったもの(水戸 将弥 [サイボウズ])
サイボウズの働き方についてのお話。
スピーカーの方はマネージャーで、オフィスにいなくてもマネジメントできる手ごたえを掴んだらしいのですが、
セッションで具体的なマネジメントについて語られることはありませんでした。
リモートでのマネジメントのイメージがわからなかったので聞きたかった。
プロジェクトマネジメントはツールでなんとかなりそうだけど、評価や勤怠管理はどうなってるんだろう。
商売よりも育児が大事という考え方は素晴らしいですね。
以下は、制度、ツール、風土についてのメモ。
- 制度
- 各自が理想的な働き方を宣言
- 好きな時間と場所を選んで働けるウルトラワーク
- ツール
- kintone
- タスク管理、議論、ひとりごと、勉強会資料置場、カレンダーなど
- Skype for Business
- 在宅用PC
- kintone
- 風土
- 在宅中心の働き方
- リアルを重視
- 振り返り/KAIZEN。
- HRT(謙虚 Humility, 尊敬 Respect, 信頼 Trust)。心理的安全性。自己組織化。
リモート開発に必須なもの。制度、ツール、風土 #devsumiD
— 山野 健太 (@yamano3201) 2018年2月15日
公明正大。アホはいいけどウソはダメ #devsumiD
— 山野 健太 (@yamano3201) 2018年2月15日
商売よりも育児が大事 #devsumiD
— 山野 健太 (@yamano3201) 2018年2月15日
【15-G-4】Machine Learning on AWS(桶谷 拓也 [アマゾン ウェブ サービス ジャパン])
個人的に注目しているMLaaSのSageMaker。近いうちに触ってみたい。
Greengrass ML Inferenceはまだプレビューですね。
ネットワークの遅延すら問題になるような環境ではエッジでの推論が求められたりするようです。GAしたら触ってみたい。
Amazon SageMaker。読み方はアマゾン セイジメーカー #devsumiG
— 山野 健太 (@yamano3201) 2018年2月15日
Greengrass ML Inference エッジ側で学習済みのモデルにより推論を行うことができる #devsumiG
— 山野 健太 (@yamano3201) 2018年2月15日
【15-D-4】Amazon Alexa Skills開発におけるAWSとの連携(亀田 治伸 [アマゾン ウェブサービス ジャパン])
Alexa Skills開発のの基本的なお話。
以下は過去記事。
yamano3201.hatenablog.jp
1個のインテントに対して10個以上の表現を推奨 #devsumiD
— 山野 健太 (@yamano3201) 2018年2月15日
【15-A-6】次世代配車アプリ「タクベル」のシステムアーキテクチャー(小林 篤 [ディー・エヌ・エー])
特定のタクシー事業者に依存しない、タクシー配車共通スマホアプリのお話。
背景は高齢化、都市化が進んで車と都市空間の奪い合いが始まるので社会問題を解決したいとのこと。
テック企業だけあって、UI/UXも含めて作りこまれている印象。
各分野の製造業は危機感を持ったほうが良さそうですね。
印象的だったのは技術の向き合い方として仲良くなるというのを重視しているところ。
自社で高い技術を持っているDeNAも、クラウドベンダーと協力してビジネスを行っているんだなぁと感じました。
以下、メモ。
- ITS(Intelligent Transport Systems) Algorithm
- UserApp
- 外部情報と連携
- Hardware
- Androidから毎秒あげている
- BLE Loggerは同じモノで対応
- DriverApp
- MDM。セキュリティ要件
- IoT Server System
新しい技術との向き合い方は2つ。足を使う、仲良くなる #devsumiA
— 山野 健太 (@yamano3201) 2018年2月15日
Alexa Skills Kit + IRKitを使って家電を操作する
前回は、IFTTTを使って家電を操作してみました。
yamano3201.hatenablog.jp
今回はAlexa Skills Kitを使って家電を操作してみます。下の2つの記事を参考にしました。
Alexaスキル開発トレーニングシリーズ 第1回 初めてのスキル開発 : Alexa Blogs
7. 自作した日本語のAlexa SkillをEcho dotで動かす - Qiita
設定が終わると、「Alexa、アイアールキットでテレビをつけて」と話しかけると、テレビをつけることができるようになります。
流れを書いていきます。
- Amazon DeveloperアカウントとAWSアカウントを作成
- Alexa Skills Kitを作成
- Lambda関数の作成
- Lambda関数の更新
- Alexa Skills Kitの設定
- Skills Beta TestingでEchoを動かす
- スキル有効化
- 最後に
Alexa Skills Kitを作成
まずはAmazon Developerアカウントで作業します。
スキル情報
- スキルの種類
- カスタム対話スキル
- 言語
- Japanese
- スキル名
- IRKitSkill(任意)
- 呼び出し名
- アイアールキット(任意)
ここでは呼び出し名が重要になってきます。
次に対話モデルを作成していきます。
インテントスキーマ
{ "intents": [ { "intent": "TargetOnIntent", "slots": [ { "name": "Target", "type": "LIST_OF_TARGETS" } ] }, { "intent": "TargetOffIntent", "slots": [ { "name": "Target", "type": "LIST_OF_TARGETS" } ] } ]}
Intentは機能と紐付いています。ここではターゲットをオンにするIntentと、オフにするIntentを用意しました。
slotsは項目と紐付いてます。同じオンにするIntentでも項目は複数あるので必要な分だけ用意します。ここではターゲットとしました。
カスタムスロットタイプ
- LIST_OF_TARGETS
- テレビ | リビング | エアコン
slotsを3つ用意しました。ここではslotsのtype名を指定します。
サンプル発話
TargetOnIntent {Target} をつけて TargetOffIntent {Target} を消して
Intentと呼び出し方を紐付けます。slotsを使用する場合はslotsのnameを{}で指定します。
IDを確認
Lambda関数の作成で使うのでIDを確認しておきます。左上に表示されています。
amzn1.ask.skill.xxxxxxxxxxxxxxxxxxxxxx
Lambda関数の作成
ここからはAWSアカウントで作業します。
一から作成
- 名前
- IRKitSkill (任意)
- ランタイム
- Python3.6
- ロール
- IRKitSkillRole (任意)
- Lambdaに信頼関係があり、AWSLambdaBasicExecutionRoleのポリシーがついたロールを作成します。
- IRKitSkillRole (任意)
Lambda関数の更新
ローカルで作成したものをzipにしてアップロードします。
ここからはローカルで作業します。
モジュールインストール
まずはrequestモジュールをインストールします。
$ sudo /usr/bin/pip-3.6 install requests -t .
コード作成
続いてlambda_function.pyを作成します。
説明のためにコードはシンプルにしています。
import requests import json def post_message(clientkey, deviceid, data): message = { "format": "raw", "freq": 38, "data": data } params = { 'clientkey': clientkey, 'deviceid': deviceid, 'message': json.dumps(message) } res = requests.post( 'https://api.getirkit.com/1/messages', params=params, headers={'Content-Type': 'application/x-www-form-unlencoded'} ) print(res.status_code) def lambda_handler(event, context): intent = event['request']['intent']['name'] target = event['request']['intent']['slots']['Target']['value'] clientkey = 'XXXXXXXXXXXXXXXXXX' deviceid = 'XXXXXXXXXXXXXXXXXX' data_hash = { 'TargetOnIntent': { 'テレビ': [18031,8755,1190...], 'リビング': [17421,8755,1232...], 'エアコン': [6881,3341,904...] }, 'TargetOffIntent': { 'テレビ': [18031,8755,1190...], 'リビング': [17421,8755,1111...], 'エアコン': [6881,3341,904...] } } data = data_hash[intent].get(target) post_message(clientkey, deviceid, data) if intent == 'TargetOnIntent': text = f'{target} をつけました' elif intent == 'TargetOffIntent': text = f'{target} を消しました' response = { 'version': '1.0', 'response': { 'outputSpeech': { 'type': 'PlainText', 'text': text } } } print(text) return response
clientkey, deviceid, 赤外線Dataは事前に用意しておきます。
Intentとslotsによって赤外線Dataが変わるので、そのようなハッシュ値をもたせています。
zipにしてアップロード
$ zip -r lambda_function.zip . $ aws lambda update-function-code --function-name IRKitSkill --zip-file fileb://lambda_function.zip
事前にクレデンシャルかIAMロールを準備しておきましょう。
トリガー作成
- トリガーの追加
- Alexa Skills Kitを設定
- アプリケーションID
- Alexa Skills Kit作成時に確認したID
Alexa Skills Kitの設定
再びAmazon Developerアカウントで作業します。
Skills Beta TestingでEchoを動かす
実際に持っているEchoで動かすには、Skills Beta Testingに登録する必要があります。
公開情報やプライバシーとコンプライアンスを入力しないと登録できないので注意。
公開情報を入力する。
アイコンの入力が必須です。
プライバシーとコンプライアンスを入力する
入力する。
Skills Beta Testingに登録する
Echoと紐付いているAmazonアカウントのメールアドレスを登録します。
メールがくるので、JP Customersというリンクをクリックします。
スキル有効化
最後にAlexaアプリからスキルを有効化します。
最後に
内容的にも公開する予定がないものなので、Skills Beta Testingで動かせたので一旦終了。
これで「Alexa、アイアールキットでテレビをつけて」で動くようになりました。
Alexa + IFTTT + IRKitを使って家電を操作する
Echo dotがやっと届いたので、試してみました。
まずはAlexa(Echo dot) -> IFTTT(webhooks) -> IRKitで家電を操作してみました。
プログラミング不要でIFTTTの設定を行うだけなので簡単です。
Alexa、IFTTT、IRKitは設定済みの前提で書いてます。
設定が終われば、「Alexa テレビをつける をトリガー」と話しかけると、テレビをつけることができるようになります。
IFTTTで新しいAppletを作成します
トリガー
Alexaの「Say a specific phrase」をトリガーとして作成します。
「What phrase?」には呼びかける定型文を入力します。
※「テレビ」ではうまく認識されなかったので、「テレビをつける」としています。
アクション
Webhooksの「Make a web request」をアクションとして作成します。
以下の値を入力します。
- URL
- Method
- POST
- Content Type
- application/x-www-form-unlencoded
- Body
- clientkey=XXXXXX&deviceid=XXXXXX&message={"format":"raw","freq":XX,"data":[XXX,XXX,]}
※「clientkey」「deviceid」「message」は事前に確認しておきましょう。http://getirkit.com
最後に
定型文と少しでも異なるように話しかけたり、トリガーって言わなければならなかったりが気になります。
Alexa Skills Kit、Alexa Voice Serviceを使えば解決できるみたいなので、少し触ってみたいと思います。
欧州一般データ保護規則(GDPR)についての個人的解釈
いよいよ2018年5月に適用が開始されるGDPR。
GDPRとは
"今回提案されたEUの新たなデータ保護制度はEUデータ保護法の対象範囲を、EU居住者のデータを処理する外国の全ての企業に拡大する。EU全域のデータ保護規制を一致させることで、欧州以外の企業が規則を遵守しやすいようにする。しかし、これを実現する代償として、データ保護を厳格に遵守させる制度、つまり全世界の売上高の4%を上限とする厳しい罰金を導入する。"欧州議会版では過料は5%に増額された。しかし欧州議会、欧州委員会、欧州閣僚理事会の三者の交渉の後、GDPRの文言、および、遵守しなかった場合の金銭的罰則についても全般的な合意がなされた
AWS
AWSの責任範囲については問題なさそう。
aws.amazon.com
欧州含む全世界向けサービス提供者例(ZOZOSUIT)
日本から欧州含む全世界向けにサービスを提供しようとしているZOZOSUITもGDPRが課題になりそうな記事が出ていました。(ZOZOSUITのインフラがどこで動いてるかはわかりませんが)
ZOZOSUITに死角ありーー世界のデータサービス業界の景色を一変させる「GDPR」とは | AMP[アンプ] - ビジネスインスピレーションメディア
いくつか記事から引用。
日本で包括的に世界のユーザー情報を管理する、という設計自体成り立たない。
EU圏内の個人データの処理に関して言えば、子会社をEU圏内に設立するというのが一番現実的なオプションだと思います。
法的な対策をとれば一部のデータ移転の可能性もゼロではありません。しかし、消費者一人ひとりとそのような契約を結ぶのはコスト・時間を考慮すると現実的とは言えないでしょう。
EUのユーザーに関してはEU法人が個別に管理する。
企業は付け焼き刃の対策で既存のモデルをGDPRに対応させようとするのではなく、ユーザーとなる消費者の思いを含め、ビジネスの初期段階から個人データ保護についてしっかりと考えなければいけません。
個人的解釈
消費者一人ひとりと契約を結ぶことは現実的ではないということで、
日本からEU圏内にビジネスを展開する場合は、EU法人を作ってデータを独立させるしか解決策がなさそうに見える。
解釈があってるかどうかは自信なし。