1時間でクラウド型コンタクトセンターを構築できるようになる！無料Amazon Connectハンズオンセミナーに参加した。
その時のメモ。ハンズオンは後日記載する。そして大変有益だった

いままでのコールセンターの悩み

・構築にあたって、高額なハード、構築費が必要になる
・スケールアップにあたって、追加のハード、構築費が必要にある
・企業システムとの連携は難しい
⇒これらを解決したのがAmazon Connect

Amazon Connect概要

・最初の顧客はAmazon。7万人くらいのオペレーターがいる(つまり7万人が同時利用可能ということ)
・ブラウザ上で電話を受けることができるため(CCP)、パソコンとヘッドセットがあれば完結する
　またクイック接続という機能で既存の電話番号に転送可能
・Direct Dialは直通番号(例えば東京だと03番号)で、ハンズオン時は枯渇していた　
・電話対応者のスキルに応じて、電話の振り分けが可能
・電話番号に応じて、太客は優先的に対応するといったことも可能
・よく電話がかかってくる時間や、よくある質問などもまとめることができる
　これによっていつどのようなスタッフを配置するか決定しやすくなる
・電話で利用する音域とは違う音域を利用しているらしく、通常の電話よりもクリアらしい
・従量課金制(数分単位での課金)
　DIDの場合、使用料金1分0.018USD、電話番号保持料金が1日0.10USD、受信通話が1分0.003USD、送信通話が0.10USD
・03番号が必要な場合はAmazonに問い合わせる必要がある。審査後に取得可能
・電話した時の最初に「ぴろろ」となるのは今のところ仕様とのこと
・シドニーリージョンは日本の番号を利用することができる

ユースケース

・IVRによるキューの分岐が可能(IVR：○○の場合は1を、△△の場合は2を押してください)
・顧客とエージェントの会話はすべて録音が可能
・外部に電話業務を委託した場合、番号を委託業者に知られずに、委託業者から顧客に電話をかけることも可能
・非通知やブラックリストの電話番号は「申し訳ありません。番号を通知してからかけなおして、、」的なことも可能
・営業時間外(祝日や会社都合、営業時間帯)の設定はAmazon Connect標準ではできないため、Lambdaで実装する必要がある
・自動予約を受け付けることが可能
・複数人電話対応者がいたときはAvailableが一番長い人に電話がかかる
　5秒(AWSの規定値)待ってでなければ、他の人に割り振られるという挙動らしい

日本ではできないけれども、近々利用できるようになるであろう機能(英語であれば実装可能)

・Amazon Lex(チャットボット)との連携
・Amazon Transcribe(音声をテキストに変換するサービス)との連携、顧客とのやり取りをリアルタイムで文字出力可能
・アメリカでは今利用している番号をConnectに紐づけることができるらしい(これはゆくゆく実現すればよいなレベル)

第3回 Amazon SageMaker 事例祭り + 体験ハンズオンに参加した。
その時のメモ。

SageMakerはセージメーカーと呼ばれていた
初めてAmazon Japanの新オフィスはとても綺麗だった

Amazon SageMakerとは何か アマゾン ウェブサービス ジャパン株式会社 ソリューションアーキテクト 鮫島 正樹 氏

今までの機械学習開発の欠点とSageMakerについて

・モデル作成にあたり、開発と学習を同じ1台のインスタンスで実施することが多い
・環境構築、運用が死ぬほど大変(複数ライブラリやGPUのドライバー、分散学習や学習結果の管理など)
・推論用のAPIなどを準備することも大変
⇒これらの問題点をすべて解決したのがSageMaker

SageMakerの特徴

・数分で開発環境が起動でき、学習、推論環境は柔軟にスケールする
　・特徴的なのはSDKやコンテナがほぼオープンソースであること
　・開発と学習環境は完全に分離されている。開発はJupyter Notebook(機械学習のコードを開発、実行可能なノートブックインスタンス)で行う
・実運用における必要な機械学習パイプラインもサポートしており、本番環境へのデプロイもスムーズに実現可能
・開発、学習、推論、いずれかをAWSで対応することが可能
　開発、学習をAWSで実施し、モデルをオンプレミスの環境に適用するということもできる
　またDockerが動く環境であればSageMakerの学習、推論ジョブを実行することが可能(例えば手元のMACでも)

SageMaker構成

・機械学習に必要なものは、学習データ、機械学習のコード、実行環境の3つ
　・学習データはS3におく
　・実行環境はECRにコンテナイメージをおく(TensorFlow,mxnetなど)
　　・これらの3つを結びつけるのがSageMaker
・学習が完了すると、モデルと学習コードはS3に保存されて、学習用インスタンスは自動的に削除される
・できたモデルをもとに、推論を実施する

機械学習パイプライン全体を支援する仕組みが用意されている

・現画像の容量が大きすぎる、欠落データが存在するといった場合は、自動的に前処理(Pandasを利用)することが可能
・S3からのファイル転送方法は2種類ある

・17種類のアルゴリズムを用意している(ビルトインアルゴリズム)
　このアルゴリズムについては自分たちで書くよりも、こちらを利用することをオススメする


・分散学習については、プログラムにtrain_instance_count=2 などで実装することが可能
・SageMaker Ground Truth
　Amazon Mechanical Turkは、Amazonのチームにてアノテーションされる

・CloudWatchにて精度が上がらない場合は停止するようなことも可能

・モデル変換(SageMaker Neo)とはモデルの高速化を実現する。モデルコンパイラと呼ばれるもの

ユースケース

・Dely：レシピ動画のリコメンデーションを機械学習で実装(90日で機械学習モデルを構築し、本番環境にデプロイ)
・SmartNews：ニュース記事の分類に利用し、関連性が高い記事を提供することに成功
・GE Healthcare：レントゲン写真から病気が疑われる部分を自動診断する

Amazon SageMaker 事例紹介「SageMaker Neoの可能性について」 株式会社ディー・エヌ・エー 加藤 倫弘 氏

DeNA × AI

・DeNA × AIにてAIに対しての取り組みを紹介している
・交通事故低減に向けたDeepLearning
　ドライバーの顔・環境モニタリング・センサ解析・地図から危険運転かどうか判定する

エッジデバイスでのDeepLearningについて

・エッジデバイスでDeepLearningする場合、動かないことやGPU前提のため動いても遅いことが多い
　エッジ側のフレームワークは非サポートOperatorがサーバ側より多く、モデル設計の上に制約が生じる
⇒それを解決したのがSageMaker Neo
　任意のモデルを任意の環境(例えばRaspberry Pi)で動作できるようにコンパイルする

Amazon SageMaker 事例紹介「1人でも使えるSageMaker」 クックパッド株式会社 染谷悠一郎 氏

クックパッドと機械学習

・300万品以上のレシピデータ(分量や作り方など、多少構造があるデータ)を活用したいという想いが以前からあり
　2016年7月より研究開発部が発足した。初期は3名、現在10-15名体制で機械学習に取り組んでいる
・料理きろくという機能で機械学習を利用している
　スマホの写真のうち、料理写真を自動的に収集し、カレンダーと結びつける機能(27万人以上のユーザが利用している)
・現状の学習機能はGPUインスタンスのオンデマンド利用しているが、常にGPUを利用している作業をしているわけでなく
　GPUインスタンスは高価であるため、学習前後のロスタイムが大きく、SageMakerに切り替えるメリットはあるとのこと

babysage – 近日公開予定

・独自モデルの学習は覚えることが多い(コンテナなど)ため、それを軽減するために作成したツール
・SageMaker(特にTraning job)を利用する際の補助となる

質疑応答

jupyterでの複数開発が難しい

⇒1人1リポジトリで集中管理がベストプラクティス

ハンズオン

Jupyter Notebook インスタンスを起動し、開発、学習、推論を実施した
ポイントはGitリポジトリで以下のURLを指定すること
https://github.com/aws-samples/amazon-sagemaker-examples-jp

【第4回】サイバーセキュリティ勉強会2019 in 塩尻に参加した。
その際のメモ。そのさん。

SPREADの活動と取り組みの紹介 一般社団法人セキュリティ対策推進協議会（SPREAD)

・スローガンは「困っている人や自分で対策できない人を置き去りにしない」
・会員向けSNS(Workplace)があり、会員が解決できなければ他の会員に聞ける仕組み
・セキュリティブログも運営している
　http://kininarublog.spread.or.jp/

試しに

サポーターになってみようと思ったが、今は募集期間ではない模様

検定スケジュール

ハニーポットと秘密のファイル @morihi_soc氏

ハニーポットとは

・攻撃を受けることが前提のシステム
・ハニーポットを運用する人をハニーポッター
　morihiさんはハニーポッター6,7年目
・低対話型：実在するソフトウェアを模倣する方式
　通常の機能では足りないため、自作している
　・SSHハニーポットはリモートアクセスしてきた攻撃者の入力OSコマンドを記録して観察する
　・WEBハニーポットはHTTP要求を受け付ける
・2013年はバックドア対策であったが、最近はマイニングプログラムが多い
・ハニーポットが好きすぎて、攻撃者をもてなすWOWHoneypotを作成した

OWASPと名古屋 OWASP名古屋

・チャプターを立ち上げるためには、OWASP本体と英語でやり取りする必要がある。大変だったらしい

パネルディスカッション

・イントラネットに古いサーバがある
⇒発生する確率と重要性を考えて、リスクを検討するべき。イントラのほうが盗むことが難しいのは確か
　イントラについても私の手にかかれば、2日あれば侵入することができる by 上野さん

・最近の脆弱性情報について
⇒脆弱性公開による攻撃がある。公開直後に攻撃がくることも。そのためには自分たちが何を利用しているか把握することが大切

・検索によって感染するリスクについて。特に広告
⇒エンドポイントでURL通信先の評価、OSなどを最新にする

・こどもへのセキュリティについて「さわらせない、みせない」をどうにかしたい。
⇒その投稿親に見せられる、見せられないなら鍵をかけないといけないよ、と実体験を伝えることでセキュリティの意識が芽生えるかも

【第4回】サイバーセキュリティ勉強会2019 in 塩尻に参加した。
その際のメモ。そのに。

法人を対象とした最近のサイバーセキュリティの動向と信州大学の対策 国立大学法人 信州大学　不破泰 教授

Society 5.0とは

・セキュリティの話をすると周りと被るため、Society 5.0の話をする
・Society 5.0ではキーボードなどからのインプットが、よりシームレスになる

Society 5.0を支える根幹技術

5Gについて

・低電力でありながら、今までとは比較にならないくらい遠くまで通信可能(が、遅い)
　(駒ヶ根市役所屋上から登山者端末と通信できる。距離にして約8km。登山者の見守りに利用している)
　登山道から外れるとキャリアの電波は届かないため5Gは有益
・高速、低遅延、多数接続の3つとも満たすことは難しい。どれかが優先されてしまう
・5Gでつながる世界 – 総務省
　https://www.youtube.com/watch?v=ArRWXopUHAQ
　低遅延通信であるからこそ、よりリアルタイムな処理が可能に

信州大学での取り組み

・正しく5.0の世界を迎えられるようにセキュリティを向上させている
・大学の教員は人から言われてやることは大っ嫌いなため、仕組みで対処するようにしている
　LACによるセキュリティチェックしないとサーバを構築してはならないというルールを作り
　チェック費用は先生の研究費からとすることで、800台のサーバが100台に減った
・LACにて、年2回の脆弱性チェックしてもらうようにしている

不正プログラムの脅威と対策 トレンドマイクロ株式会社 田中 啓介 氏

・通信先評価機能などがウイルスバスター標準で導入されているので、利用してみるとよいかも

脆弱性診断やってみた ～プラットフォーム診断編～ 株式会社 電算 内山巧 氏

脆弱性診断とは

・弱そうなところをまず調べてから、脆弱性がないかどうか判断している

・A社が公開した脆弱性とB社が公開した脆弱性が被らないように、共通の識別子で管理されている

脆弱性診断の種類

・脆弱性診断にレイヤーごとに診断名が異なる

脆弱性診断ツール

・QoDは、信頼性を表し100%のときは確実に脆弱性があるということ

まとめ

・20年前はウイルス対策ソフトが入っているのは当たり前ではなかった
　今は入っていないと責められるレベルまで普及した
・特別な脆弱性診断から当たり前の脆弱性診断へ

【第4回】サイバーセキュリティ勉強会2019 in 塩尻に参加した。
その際のメモ。そのいち。

今年から塩尻市が主催している(3回目までは有志)
http://www.city.shiojiri.lg.jp/gyosei/shisaku/johoka/sybersecurity2019.html

サイバーセキュリティの学び方 ～楽しく、みんなで学ぼう～ 株式会社ラック　長谷川長一 氏

・今年は会社に7時間しか行っていない
・LACについて長野県と連携している(ラック、信州大学と長野高専、長野県警との四者による産学官連携協定を締結)

IPA情報セキュリティ10大脅威

・1次ソースはない
・被害金額や件数ではなく、有識者の投票で決めている(今後の懸念という意味が大きい)
・時期的に徐々に早く公開され、詳細も公開されるようになった
　理由は学校機関や企業からの要請。3月公開だとシラバスや新人研修に間に合わない
・ラックが公開した「外部からの攻撃により発生した重要インシデント」にはSQLインジェクションやXSSが上位になっている
　しかしIPA情報セキュリティ10大脅威には入っておらず、つまりは殿堂入りしているのだろうw

IoTのマルウェア Mirai

・2016年11月、世界的に拡散。現在も攻撃は続いている
・感染機器はIPカメラ、DVR、ルーターで9割を占める
・人が入らない部屋、人が出入りする部屋、女性の服がかかってる部屋にIPカメラを仕込むと、女性の部屋が一番お客さんが多かった

実践的なセキュリティに必要なスキル

・シナリオ思考
　ログなどから何が原因で今何が起こっているかを想像する能力
・これから起こることを予測し、防止しないといけない
　例えば火事が発生したら、周りに火が移らないように守りつつ、消火する
・非対称性があるため、管理者は攻撃方法を知る必要がある
　攻撃者は攻撃対象がよく見えているが、逆はあまり見えていない

実践的なセキュリティ人材を育成するには

・なるべくシナリオベースの実践的な演習と訓練をすること
・独学での一番の問題点は独善的な結果になりやすい
　孤独であることは我慢しよう、大した問題ではない
・ラーニングピラミッドにもあるように人に説明することが一番定着率が高くなる

サイバー犯罪の現状について 長野県警察本部 生活安全部生活環境課 サイバー犯罪対策室

・不正アクセスやフィッシングサイトを構築しているのは未成年が多い。興味でやれそうだからやってみたという理由が多い
　完全なプロはそもそも捕まらないのだろうか。。

不正アクセスにはならない案件

・友人から認証コードが送られてくるから教えてほしいという連絡があったため伝えたところ、SNSが乗っ取られた
⇒システム管理者に確認して、これは不正アクセスにならないという判断になった(過去事例で今は見直し中？)

・ゲームアカウントを売った。アカウントは渡したが金額は受け取れなかった
⇒アカウント管理者のゲーム会社は利用規約であるアカウントの売買や譲渡を認めていないため、救済処置はなし

対処しようのない案件

・デジタルタトゥーや画像が流出した場合
⇒当たり前であるが削除は難しい。特に海外のサーバについては法律が異なり、そもそも削除要請もできない

OWASPを知れば変わるセキュリティ対策 OWASP Japan Chapter Leader 上野 宣 氏

・OWASPは世界最大のセキュリティコミュニティ
・2011年から日本での普及を始めている

Webサイトを安全にする7つ道具

・セキュリティの問題は一通り出そろっている

1.サイバーセキュリティ経営ガイドライン

・経営課題とするために、どのように経営者に伝えるか？
・IPAが解説書を出しているため理解しやすくなっている

2.OWASPアプリケーションセキュリティ検証標準(ASVS)

・自分たちに必要なセキュリティレベルを知る
・OWASPの文書は英語が多いが、jpcertに協力してもらい日本語版がある

3.Webシステム/Webアプリケーションセキュリティ要件書

・安全なWEBアプリケーション開発の具体的なセキュリティ要件書
・これをもとに開発すれば安全なWEBアプリケーションができあがる
・情報漏洩事件でシステム発注者側が開発者側に勝訴した判例がある
　IPAなどから資料が出ておりセキュアな開発は当たり前という時代になっている

4.安全なウェブサイトの作り方

・セキュリティを初めて意識するWEBアプリケーション開発者向けドキュメント

5.Webアプリケーション脆弱性診断ライン

・脆弱性診断を行うためのガイドライン(そもそも診断の基準がなく、作ろうとしたことがきっかけ)
　例えば自社のアプリケーションの脆弱性を見つけるときに、いままではその基準がなかった
・上野さんはBurpを利用されており、オススメらしい

6.WAF

・新しい攻撃があったときに、アプリケーションを修正せず、WAFのルールでブロックできることが最大のメリット
・SQLインジェクションされたときにデータが何件抜かれたかなど調べることは難しい。そのためのログとして取得する利用方法もある
・apacheであればmodsecurityを入れてもよいかも

グッド・プラクティス・ガイドパッチ管理

・すべてのシステムにパッチを適用するためのガイドライン
・いまさらチェックできない
　OWASP Dependency Checkを利用すれば、webアプリケーションに組み込んだコンポーネントのパッチ未適用を検出可能

時代に合わせたセキュリティ対策

・NISTデジタル認証ガイドラインにて、様々なパスワードに対しての制約が決まっている
　定期的なパスワードを必須とすると、パスワードの後ろの数字が増えるだけであまり意味がないため
・TLS1.0もPCIDSSにて2018年6月30日から利用禁止
・初回のぺネストレーションテストで侵入できなかったことはないby上野さん
　https://www.tricorder.jp/penetration_test/
・セキュリティインシデントは起こることを前提に考えるべき

さくらのCDNサービス（ウェブアクセラレータ）セミナーに参加した。その時のメモ。

さくらのCDNのメリット

【第一部】ご利用ユーザによるセッション①　登壇者：トゥギャッター株式会社　吉田様、青山様

Camoについて調べていたら、記事を見つけた。以下にすべて記載されていた。
https://qiita.com/MintoAoyama/items/6cd71b84e6225f86f819

トゥギャッター(海外版はChirpStory)について

・2019年で10周年
・月間1億PV
・月間UU1200万UU
・月間3TBくらいの通信量

camoについて

・「カモフラージュ」からきているらしい
・リアルタイム変換機能付き画像プロキシサーバ(atmos/camo)
・脆弱性を突かれた場合や直接URLが変更できた場合、意図せぬコンテンツを取得しないようにURLの一部を暗号化可能

ウェブアクセラレータについて

・camoはさくらのクラウドに2台(石狩・東京)配置していたが、大阪にユーザが多くレイテンシが気になっていた。
・以下のメリットがあり、さくらのウェブアクセラレータを利用することに。
　・エッジサーバが大阪にあった
　・価格が1/5くらいになった(他社と比較して)
　・導入にあたってさまざまなつぶやきを拾って対応してもらえた
・今後オリジンサーバはArukasにするかも？

懇親会で聞いたこと

・さくらインターネットからImageFluxというサービスが提供開始されており、これと同じことを実装している。

【第一部】ご利用ユーザによるセッション②　登壇者：株式会社ALiNKインターネット様

登壇者 – 松本修士氏について

・tenki.jpを運営している会社のCTO
・元Yahoo!天気エンジニア
・未来の予定を晴れにする会社
　雨の時にどうすればよいか？を提供できるようにする。
・C言語以外はすべてPerl – 来たれR35Perlハッカー

さくらのCDNについて

・さくらのCDNを2016年のベータテストから利用している
・国内で安定していることがメリット
・国内がゆえにオリジンサーバとの距離が近い
・相談しやすい(直接電話していろいろ試せる、他社は全体的な障害には対応するが、なぜかウチだけ障害は対応してもらえることは少ない)
・他CDNと比較してメリットが多かった
　Akamai：安定はするが高額
　Azure CDN：2時間くらい落ちた(旧ver)

tenki.jpとCDN

・CDN + nginx + 専用サーバ(40C/80T)
・地震発生後～3分程度でトラフィックが約200-300倍に跳ね上がる。最近だと1分の平均で2.5Gbsを計測した
　(台風などと違って計画的なサーバ投入が難しいため、CDNがキーとなる)
・更新速度命とキャッシュシステムが相反する考え方になるが、負荷とのバランスをとっている

懇親会で聞いたこと

・5分ごとに更新される豪雨レーダーについてはCDNのキャッシュ全削除とキャッシュヘッダーを5分以内にすることで実現している
・CDNについて、一応他社も契約して何かあった時に切り替えられるようにしている

ハンズオン

CDNメリット

・インフラ側の対応の遅れによる機会損失を抑制
・対応するエンジニアの運用コストの省力化や緊急対応時の疲弊を緩和

さくらのCDNについて

・さくらのクラウドを利用することで、低レイテンシーとなる
・他社の仮想マシンとも連携できる
・キャッシュするかどうかはCache-Controlヘッダーにて制御する
・ネイキッドドメイン(https://test.jp/などサブドメインがないもの)では利用できない
・設定項目は以下のようにシンプルだった