英語の勉強のために観た海外ドラマ(のまとめその1

外資系の会社で働くことになったので英語の勉強を始めるなど - リンクとか備忘録とか日記とか
のエントリーの続き。
とりあえず今のところ以下のドラマを観た。

以下、評判とかはググってもらうとして個人的な雑感。ネタバレは書かないつもりだけど気になる人のために続きを読むにしとく。

続きを読む

Ops JAWS Meetup#15 IAM勉強会 with 熊本支部(参加メモをただ貼る

Ops JAWS Meetup#15 IAM勉強会 with 熊本支部
https://opsjaws.doorkeeper.jp/events/74118

■OpsJAWSご紹介
○アンケート
https://goo.gl/PSs34p

■熊本支部の紹介
JAWS-UG熊本 第10回勉強会
熊本地震の時はmizuderu作ってました
http://mizuderu.info/

■リモートについて
Amazon Chime使ってる

==========
素晴らしきIAMポリシービジュアルエディターの世界(サーバーワークス 伊藤様)
簡単にこだわりのポリシーを実現
https://www.slideshare.net/qryuu/iam-98065746

AWSの操作権限

  • rootアカウントが必要
    • メール送信制限解除申請
    • CloudFrontキーペアの作成
    • 契約情報の変更

■IAMリソース

  • IAMユーザー
    • ログインユーザー、APIユーザー
  • IAMグループ
    • IAMユーザーをまとめて管理するグループ
  • IAMロール
    • ユーザーの役割を一時的に切り替える
    • EC2やAWSサービスに対して権限を割り当てる
  • IAM管理ポリシー
    • 権限を汎用的に管理する

■IAMポリシー

  • IAMリソースに対して設定
  • JSON形式で表現される権限設定
    • Effect
    • Principal, NotPrincipal
    • Action, NotAction
    • resource, NotResource
    • Condition
  • 人類には早すぎるJSON形式
    • アクションを指定するのにAPIドキュメントの熟読が必要
    • ARNのコロンの数を覚えないと
    • コンディション書式はドキュメントでもわかりづらい

■IAMビジュアルエディタ
サービス
アクション
リソース
リクエスト条件

  • ビジュアルエディタでは、サービスごとにポリシーを簡単に設定できる
  • サービスを選択
  • アクションでは、一覧、読み込み、書き込み、権限設定の種類ごとに簡単にチェックボックスで選択可能
  • リソース制限
    • 許可したアクションの中にリソース制限が可能な操作があれば、自動的に指定可能なリソースの種類が表示されます。
    • すべてのリソースを指定することも、個別のリソースを指定することもラジオボタンで選ぶだけ
    • リソースタイプが自動的に分かれるので、指定も簡単
    • [ARNの追加]をクリックするとわかりやすい入力欄が現れるのでコロンの数を間違えることがありません。
  • リクエスト条件
    • MFA必須や特定IPアドレスからの操作のみ許可のような宣言はチェックボックスをチェックするだけで設定可能
    • [条件の追加]をクリックすれば、タグベース条件なども簡単に設定可能
    • APIの使用に合わせて条件キーリストが自動的に変わるので、APIドキュメントを見なくても、設定できる条件だけが表示されます(タグに対応したアクションだけが表示されるのでJSONを生で書くのに比べて安全
    • チェックボックス地獄回避
      • Describeと
      • ビジュアルエディタはJSONと併用可能、[Describe*]のように手動で編集したアクションを使って設定を行うこともできます
  • IAMビジュアルエディタの小技
    • 複雑なポロシーは分割して指定
      • [アクセス権限の拒否に切り替え]を使うことで許可と拒否とを切り替えできる
    • ポリシー変数の設定も可能です
      • IAMユーザーが自分のS3ホームディレクトリにプログラムによりコンソールでアクセスすることを許可する
    • バージョニング
      • 5つ前までのバージョンが残っている(ので設定を間違っても戻れる

■IAMビュジュアルエディタの制限

  • IAMグループポリシーに対応していない

■まとめ

  • これまでJSONなので経験やドキュメントが必要だった
  • ビジュアルエディタでは画面の警告に従うだけで細かいポリシー設定が可能
  • 過去に作ったJSONをビジュアルエディタで見ると抜け漏れが発見できる場合がある
  • ビジュアルエディタで適切な権限設定を簡単にできるようになる

JSONで書いてからビジュアルエディタにすると確認できる

==========
IAMの運用ベストプラクティス(クラスメソッド 森永様)
https://dev.classmethod.jp/cloud/report-opsjaws-13/

IAM運用どうしてます?

まずはAWS公式のベストプラクティスを見る

  • AWSアカウントのルートユーザーのアクセスキーをロックする(MFAの登録
  • 個々のIAMユーザーの作成
  • IAMユーザーへのアクセス権限を割り当てるためにグループを使用する(ポリシーでも同様のことができるのでそちらでやるのも手
  • AWS定義のポリシーを使用して可能な限りアクセス権限を割り当てる
    • 新しいサービス追加に自動で追随
    • 関連するAPIコールも追加してくれる
    • 要らない権限までつく
  • 最小権限を付与する
    • やってはいけない操作を防ぐ
    • 関係ないリソース操作を防ぐ
    • 運用が死ぬほど大変
  • アクセスレベルを使用してIAM権限を確認する
  • ユーザーの強力なパスワードポリシーを設定
  • 特権ユーザに対してMFAを有効化する
    • 特権ユーザに限らずやるべき
  • Amazon EC2インスタンスで実行するアプリケーションに対し、ロールを使用する
    • IAMユーザーのアクセスキーではなくロールを使う(アクセスキーは漏れたらおしまい、ロールは一時的なアクセスキーを発行してる
  • 認証情報を共有するのではなくロールを使って委託する
    • 1つのアカウントから別ロールへスイッチ可能
  • 認証情報を定期的にローテーションする
    • アクセスキーは基本的に使わないで、定期的にローテーションする
  • 不要な認証情報を削除する
    • アプリしか使わないユーザーはパスワード不要
    • コンソールしか使わないユーザーはアクセスきー不要
  • 追加セキュリティに対するポリシー条件を使用する
  • AWSアカウントのアクティブティの監視
    • アクセスログ、監査ログを取る
      • CloudTrail(何をやったか
      • Configでリソースの変更ログ(何を変えたか
        • Configは変更ごとに課金されるので要調整
      • CloudFront, ELB, S3などでアクセスログ
  • ひとまず個人的まとめ
    • ルートユーザーは使わない
    • IAMユーザーは使わないでロールで
    • アクセスキーは最終手段なのでロールで実現
    • ログは取る
    • MFAは基本的に有効化する(仮想でもいい
    • パスワードは強力に
    • IAMロールを使うと大体解決
  • 残った課題
    • IAMの権限をどうするか
  • 最小権限にした時のよくあるシナリオ
    • 権限不足→権限追加の嵐。つらい
  • 問題点
    • AWSは1つの操作でも複数のAPIを呼ぶことがある(完璧な最小権限を目指すのは難しい(てか無理
    • 何かやるたびに問い合わせが必要だと
  • やれる体制があるならやった方がいい

リクルートテクノロジーズさん運用事例
https://www.slideshare.net/recruitcojp/20160517-security-jaws-miyazakisachie?ref=https://recruit-tech.co.jp/news/160517_001663.html
AWSでのセキュリティ運用
(棚卸しからの見直しで1週間以上かかる…

  • PowerUser権限を渡して一部Deny
    • 基本的に全てのサービス・リソースを触れる
    • 触らせたくないのだけDeny
    • 運用ほぼなし、権限不足で悩まない、けどセキュリティ的には
    • PowerUserはIAMロールを付与できない
    • iam:PassRoleの権限をつければいける
    • iam:Get, iam:Listもつける
  • 使うサービスの権限d酒AWS管理ポリシーを渡す
    • EC2FullAccessなどの管理ポリシーを使う
    • 運用は比較的楽dさが、別のサービスを見に行くサービスがあると困るし、許可したサービスについては何でもできちゃう(ReadOnlyは全部につけておいてもいいのでは
  • 職務機能別のAWS管理ポリシーを使う
    • DB管理者、システム管理者など職務別にポリシーが存在してるので流用する
    • 足りない部分をたす。が、うまくハマればいいのでは程度
  • どれを選択するかは組織体制やしくみづくり次第
  • IAMの権限をガチガチにするより
    • 問題発生時に対応できるしくみづくりが重要では?
      • CloudTrail + AthenaとかConfigとかConfig Rulesで設定値を監視とか
    • 外部から不正利用されないようにベストプラクティスを守る(内部犯行は防げない
    • そもそも組織が違うならアカウント自体を変える
    • 認証情報レポートが棚卸しに便利
      • アカウント内のすべてのユーザとユーザの認証に関する情報が一覧にまとめられたレポート
  • まとめ
    • IAMの権限管理は自分の組織に合わせて方針を決める
    • 無理して厳しくしすぎずに即座に対応できる仕組みを
    • 運用者も開発車も疲弊しないように最善を探る
    • 自動チェックはどんどんやるべき(だが人力も必要
  • まとめ(Developers.IOに
  • QA
  • AWSではIAM管理をどうしてるのか?
    • ロールベースです。ツール使いながらロールベースで管理

==========
初めてさわるEC2ロール(熊本)山ノ内さん
https://www.slideshare.net/yoshinoriyamanouchi12/ec2-98014834

計算リソースとしてスポットインスタンスを使っているが、スポットだと突然死するのでAMIにアクセスキーを保存できないから再アクセスするのに…
→EC2にIAMロール割り当てればいいのでは

  • S3アクセスポリシーの作成
  • EC2用ロールの作成
    • 上記のS3アクセスポリシーだけ当てる
  • ロールを指定せずに起動
  • ターミナルに接続(権限不足エラー
  • 作成したロールを選択して起動
  • 指定したS3にアクセスできる
  • EC2ロールでアクセス可能なサービス → だいたい行ける

まとめ
ロールでまとめると楽

  • QA
  • ローンチテンプレートを使うともっと楽なのでは

https://dev.classmethod.jp/cloud/aws/try-launch-template-for-ec2/

==========
LT1:AWS Organizationによる権限管理(日本ユニシス 太田様)

  • AWS Organizationとは
    • マルチアカウントを管理することができるサービス(アカウント=ルートアカウント
    • 提供する機能
      • サービスコトロールポリシー(SCP)を適用して組織内のアカウントが実行できることを管理
      • 組織のアカウントの作成、管理
      • 一括請求
  • AWS Organizationsによる権限管理
    • 組織を作れる
    • ディレクトリ構造のようにアカウントを管理できる
      • rootをマスターアカウントとする
    • OU1, 2, 3, 4...(最大6階層
    • AWSアカウントに対して適用するSCPを選べる
  • SCP #1
    • サービスやアクションへのアクセス制限を許可・拒否できる
    • プリンシパルやリソースは指定できない
    • 適用範囲
      • IAMユーザーやロール、AWSルートアカウント
    • 適用対象
      • ルートにアタッチ=組織内の全てに適用
  • SCP #2
    • ポリシーの許可・拒否は以下のように機能する
    • 複数のポリシーを提供するとAND条件になる
    • アカウント内のアクセス権限痛いしてフィルタとして動作する
      • 許可
      • 拒否
  • IAMのアクセス可否
    • アクセス可否の決定ロジック(デフォルトDeny < Allow < 明示的なDeny
    • SCPを混ぜると(デフォルトDeny < Allow (IAM, SCP < 明示的なDeny(IAM or SCP
  • 適用事例
    • デフォルトのポリシー(FullAWSAccessはそのまま利用する
    • 全体に対する拒否をSCP, OUで管理
    • 個別の許可・拒否はIAMで管理
    • SCPの制限を一時的に有効にしたい場合はOUを移動して制限をはずす
    • OUは2階層
  • FullAWSAccess
    • OU1=SCP2=AWSアカウント解約を拒否
      • OU2=SCP3=EC2削除を拒否
      • OU3=SCPなし
  • とすると、EC2削除をしたい時にOU2 →OU3にアカウントを一時的に移動することで削除できるようになる
  • まとめ
  • AWS Organizationsを利用することで、複数のAWSアカウント、IAMユーザーに対して制限をかけてガバナンスを聞かせることができる
  • OU, SCPを組み合わせて柔軟な運用を実現できる
  • QA
  • 社全体に適用・普及するにはどうすれば?
  • 今回はとあるプロジェクトの範囲で適用してみた。社全体での適用は今後の課題
  • (Qを聞き逃した
  • MFAで入るアカウントを踏み台として使い、そのアカウントでは開発せず開発用ロールへスイッチロールする運用が良いのでは

Security JAWS 【第9回】 勉強会 2018年5月16日(水) 参加メモ(をただ貼るだけ

Security JAWS 【第9回】 勉強会 2018年5月16日(水) - Security-JAWS | Doorkeeper
に参加した時のメモ書き。を単に貼るだけだけど上げておく。

==========
■フューチャーアーキテクト株式会社 日比野 恒さん、中井 祐季さん
「Kibana Canvasで魅せる!AWS環境における脅威分析ユースケース
https://www.slideshare.net/hibinohisashi/securityjawskibana-canvasaws

オープンSIEM構想
シンプルな分析画面

個人情報を保持するシステム<不正監査をする仕組みでAWS導入

無償でElasticStackの性能管理ができるX-Pack Basicのモニタリング

Beats
audit beats

○脅威分析のユースケース
・外部からの攻撃
マネジメントコンソール等々のログイン行為
APIの監査

・内部犯行
踏み台への不正ログイン
S3のアクセスログ(GETのログ
SQLアクセス

※内部犯行の特定はログと作業記録との突き合わせ

○CloudTrail分析
コンソールログイン, API操作
→いつ誰がどこから

LOgstashのgeoip filterを用いて送信元IPアドレスに国情報を孵化しておく


存在しないIAMユーザーでログいんすると
HIDDEN_DUE_TO_SECURITY_REASONS

IAMUserの実行したAWS APIコールについてCloudTrail操作ログを分析する
IPアドレスで絞ってみる
・ユーザー名で絞ってみる

AWS管理コンソールへのろログインに関するCloudTrail操作ログ分析
・ConsoleLoginで絞ってみる
・MFA利用有無をNoで絞ってみる

○番外編
CLBのアクセスログからアプリの脆弱性をついた攻撃を検知
MLで異常検知
→CLBの遅延時間の大きい時間帯のアクセスで異常検知し、おかしなUserAgentを発見

Canvasの話は?
間に合わなかった

==========
■Imperva Japan K.K. 岩下 洋司さん
「WAFシグネチャとログとAI」

Imperva
https://www.imperva.jp/

Attack Analyticsの機能紹介

AWS WAFでImperva SecureSphereのシグネチャを提供してる件
マネージドルールとしてRuleセットを提供している
・IP Reputation Lists
https://aws.amazon.com/marketplace/pp/B07784QN39
WordPress Protection
https://aws.amazon.com/marketplace/pp/B077GJ99B1

競合となるAWS WAFになぜManaged Rule Setを提供するのか?
・ユーザからの要求
・自社顧客とのユーザ層の違い
AWSからの打診

IP Reputation Lists
→脅威を振りまく最新のアドレス情報を世界中の自社顧客のWAFから収集
→それ使えるの?
→75%以上のIPアドレスで攻撃があれば他の攻撃も行う


○セキュリティ装置のアラートが何かと多すぎる件
本当に必要なアラートだけに絞るには
重要なアラートを見逃さないためには

・Imperva Attack Analytics
AI, MLを活用したアラート分析

○ログ分析の分野に今後AIが盛んに利用されて行く件

USではDBファイヤーウォール製品が人気
日本ではファイル関連の製品が人気
→ポリシーを明確に書きづらい(統制を利かせにくい

==========
■株式会社NTTドコモ 守屋 裕樹さん
JAWS DAYSで話せなかった「Security x Serverless」の話」

JAWS DAYSでの公募から外れた内容

ドコモでのAWS利用
・2012年から本格利用
・400アカウントを運用中
・CCoE(Cloud Center of Excellence)チーム
→社内のガイドライン、テンプレート(共通基盤)作成
→対策方法やベストプラクティスを社内公開

クラウドの表と裏
間違った使い方も簡単にできる
ガイドラインだけでは防げない
 ・設定ミス/知識不足、

内部でScanMonsterと言う自動アセスメントツールを作成
ガイドラインに照らし合わせて間違った使い方を検知
→57のチェック項目を実装
→同一画面で複数のAWSアカウントをアセスメント可能にしてる

→できるだけお金をかけない
・Trasted Advisor
 →NG(クロスアカウントでフル機能だと高すぎる
・Config Rules
 →OK(だけどお金がかかる
AWS API
 →OK(Lambdaでリソース効率化

Zappa(Pythonベースのサーバーレスフレームワーク)でバックエンド実装

○権限管理どうやるの?
・全てIAMロールで
・クロスアカウントのアクセスはIAMロールとSTSのみ利用

○ユーザ認証はどうやっている?

○サーバレスの接続元制限
API Gateway
→リソースポリシーにてIPアドレス制限
Lambda
→Event情報として接続元情報を取得可能。関数内のロジックでIPアドレス制限可能

CloudFront + WAF
→WAFでIPアドレス制限

○ログ収集

CloudWatchで
→機密情報の送信に注意
→1024バイトを超えるログが切り捨て

Cognito User Poolsではログイン履歴、認証の履歴といったログは取得不可
DynamoDBでもGetItemのログが取得不可

CloudWatch logs
JSONで吐かれるのでコンソール上では解析が難しい

○QA
Trusted Advisorはエンタープライズサポートに入れば安くなるのでは?
→社内事情です


==========
■SecureWorks Japan 株式会社 山崎 景太さん
「攻撃者視点から考えるAWS EC2セキュリティインシデントとその対応」

Red Team Testingサービス
→物理的な侵入も含めた攻撃サービス

・外部からの攻撃によって発生するインシデント
・攻撃者の視点から考える
・○○からの攻撃
・case study

○EC2環境で発生する基本的なインシデント
・Webアプリの脆弱性
・OSコマンド実行系の脆弱性
・アクセス制御の不備
AWS管理コンソールへの不正アクセス

とはいえ発生するインシデント
・Zero-day
・予算不足
・現場の理解不足
・検証環境/開発環境のShadow化

○攻撃者の視点から考える
・攻撃ポイント
 ・社内端末、委託先端末や自宅端末(リモート端末
VPC内のシステムに侵入するためには
 ・アクセス経路が確保されている
 ・アクセスに必要な認証情報を取得する

Red Team Testing Approach
内部活動

○正規運用端末を乗っ取ると(何ができるか
・アクセス制御のバイパス
・認証情報の窃取
・侵入の拡大
いわゆるCVEに乗るような脆弱性やアクセス制御のミスがなくても侵入可能になる

○アクセス制御のバイパス
基本マルウェアに感染させて端末を乗っ取ってアクセス

スクリーンショットの取得
クリップボードの中身をダンプ

ケーススタディ

AWSコンソールのセッションタイムアウトの時間知ってますか?
→12時間
→この時間内なら端末を乗っ取っているならカレントセッションを乗っ取れる
→使い終わったらログアウトしましょう

○Wrap Up
・インターネットからの直接的な攻撃に対して必要な対策を講じておくのは当然
・社内ネットワークを経由知れば、ターゲットシステム(EC2)に侵入する経路は増える
 →内部からの攻撃を考慮して内部からの攻撃対策をしておくのが重要
・インシデントは起こる
 →のでインシデントレスポンス対応体制の整備が必要
 →攻撃を遅らせている間に対応

○EC2のフォレンジック用データの取得
・ボリュームスナップショットを取得してセキュリティベンダーへ提供
・暗号化ボリュームの場合は鍵情報も併せて

AWS
○OS内のデータのログギング
who, where, when, what

○QA
AWS管理コンソールは使い終わったらログアウトしましょう


==========
電気通信大学 手柴 瑞基さん
「自動車監視のためのクラウドソリューション(仮)」
https://speakerdeck.com/himitu23/jaws-security-09-tokyo-cloud-solution-for-management-and-observation-vehicle

OBD2ポート(CAN)
 →診断用端子
キーフォブ
コンピュータ(ECU

PiCAN、ODB-IIケーブルを用いてCAN通信を取得
→ハンドルの右下か左下にODBってポートがあるのでそこから取得できる

==========
■LT#1:株式会社NTTドコモ 神崎 由紀さん
「ドコモでのインシデント事例と対策(仮)」

(先のドコモの方と内容が被ってた気がするのであんまり聞いてない。ごめんなさい

==========
■LT#2:クックパッド株式会社 水谷 正慶さん
「セキュリティログ分析のためのサーバーレスアプリケーションの構築(仮)」
https://speakerdeck.com/mizutani/sekiyuriteirogufen-xi-ji-pan-falsegou-zhu-on-aws

https://speakerdeck.com/mizutani/korega-cloud-native-na-sekiyuriteirogufen-xi-da-jia
のブラッシュアップ版

SIEMだとクラウドでは…
・ログの送信元を動的に制御できない
・全体構成を気軽にいじれない
・ルールのテストが難しい

==========
■LT#3 T3 Realize合同会社 横堀 達也さん
「アセスメント指摘事項への対応をサーバレスでチャチャッとやる話」

Systems Manager
Logs Agent
SSM Agent

AWS Systems Manager
SSMエージェントでWindows 10 Proも管理できる(らしい
無料でクライアント端末管理できちゃう?

AWS GuardDuty Black Belt Online Seminar参加メモ(をただ貼るだけ

[AWS Black Belt Online Seminar] Amazon GuardDuty
に参加した時のメモ書き。を単に貼るだけだけど上げておく。

==========
AWS GuardDuty Black Belt Online Seminar
==========

VPC flow logs
DNS Logs
CloudTrail

GuardDutyではOS上にIDS/IPSを入れていても検知できないアカウントの不正使用などAWS内部の脅威も検知できる。
GuardDutyからのHighのアラートに対してのアクションをCloudWatch Event -> Lambdaと渡すことも可能。

GuardDuty用のIAMロールが自動作成される

デモは、amazon-guardduty-tester (github を使う
GuardDutyのテストはちゃんと侵入テスト申請をしてからやること

有効化は1クリックだけ

アタックの結果がGuardDutyに表示されるには少し時間がかかる


■検知の仕組み

Threat Detection Types
シグネチャベースではマッチングしたら閉じる
ビヘイビアベースではアノマリーを検知する

■Data Sourcesは以下の3つ
VPC flow logs
DNS Logs
CloudTrail

VPC flow logsやCloudTrailを有効化していなくてもGDで勝手に取れる

■脅威インテリジェンス=脅威と判断する定義
攻撃者のIPアドレスドメインで構成
パートナーと協力して得たノウハウとAWSセキュリティのノウハウを併せてIPアドレスドメインを判断してる

ホワイトリストブラックリスト

Findings(=脅威)
マネジメントコンソールでの確認
・重要度、頻度、リージョン、国、脅威タイプ、影響範囲、攻撃元情報
API/JSONフォーマット
getfindingsで叩く
・SIEM連携、データ活用

Finding Purpose
backdoor, behavior, crypto currency, pentest, recon, stealth, trojan, unauthorized access

Findings(脅威リスク)はどんどん自動的に追加される

■severity levels for GD Findings
High : 7.0 - 8.9
Medium : 4.0-6.9
Low : 01.-3.9

検出時のアクション
通知をトリガーにしてやりたいこと
・cloudwatch eventsからlambdaを呼び出す
severityに応じてアクションを定義できる

amazon-guardduty-to-slack (github

■Pricing
・CloudTrail Events:イベントの数
VPC Flog Logs/DNS Logs:ログの量

30日無料利用期間がある
current chargeが確認できるので、◯日経過したら30日を予測できる

■Region, multiaccount
リージョンごとに有効にしないと駄目

マルチアカウント時のGDは?
1つのアカウントで検知した脅威を他のアカウントに転送できる
アドミンアカウントに子アカウントを紐付けることができる

cloudformation (stacksets)を使うと1個のアカウントでマルチリージョンでGDを有効化するとかできる

デモは1アカウントでのマルチリージョンを実施

GDを有効化した後にログを集約する
→ログを集約管理するアカウントとログを収集されるアカウント

amazon-guardduty-multiaccount-scripts (github

■パートナー
アクセンチュア
デロイト
RedLock
alertlgic
rapid7
paloalto
evident.io
IBM
proofpoint
trend micro
logicworks
splunk
sumologic
書けないところもある感じ


脅威の検知はなかなかコストや工数もかかるので導入が難しい
→マネージド・サービスで提供されるメリット
→エージェント不要、既存環境に影響を与えない
→cloudwatch eventsの合わせ技で検知からの対応の自動化


GD Lab
http://lab.gregmcconnel.net/
Click here to download the zip file for the lab. Then unzip the file to get all of the contents of the lab.
ってzipファイルが落とせる画面が

■Q&A
環境に別のクレデンシャルを持ち込むとどうなる?
→持ち込んで試してみて

テスト実行のコマンドはgithubのテスターに含まれてるか?
→含まれてる。試してみて

レポート機能は?
→今はない
→findingsのエクスポートで今は対応。JSONで出る
→90日以上ログを保持したければ、S3に吐くなどするように


サーバレスだけ使ってる環境でのGDのメリットは?
→IAMとEC2のfindingsが多い
→サーバレスだけでもAWSプラットフォームの管理(IAMとか)ができるのでメリットある


残りのQAはブログで回答します
→質問がかなり来てるらしい。ブログに期待

PyQを始めてみた

先日、SoloLearnを始めてみたと書いたのですが。

SoloLearnを始めてみた - リンクとか備忘録とか日記とか

「スラスラわかるPython」を終えてみて、SoloLearnは理解したことのチェックには向いてるし、スマホを使って空き時間に勉強するのには向いてるんだけど、あんまり写経には向かないかなってのとどうも学んでる感が薄い気がして。

で、PyQを始めてみた。

pyq.jp

お金払うから「もったいない」と感じて一気に進められるかなと思ってw

ちょっと始めてみて、写経に向いてるなぁと思ったのと上手い具合の課題が提示されるので素晴らしいなぁ、などと。 一番最初に参考にさせてもらった以下の記事でも初心者向けに薦められてたし。

shinyorke.hatenablog.com

SoloLearnを始めてみた

以前に書いた通りちょこちょことPythonの勉強をしてるのだけど。

Pythonの勉強を始める - リンクとか備忘録とか日記とか

 

MacBook Airで環境を作ったものの、どっかでMB Airを開かないと勉強できないし、すきま時間が使えないのでSoloLearnってのを始めてみた。

SoloLearn: Learn to Code for Free!

 

これでiPhoneでもiPadでも好きな時にちょこちょこ進められるヽ(´ー`)ノ

てかこれだけ学べて無料ってすごい。

Pythonistaの導入も考えたけど、ちょっとまだ自分には早いかなぁと思ってたので、ちょうど良い具合の勉強ツールが見つかって良かった。

Pythonista for iOS

 

外資系の会社で働くことになったので英語の勉強を始めるなど

掲題の通り、6/1から外資系の会社で働くことになった。

転職だの退職だののエントリーは、まだ退職もしてないし、転職は5回目なので何か人の役に立つことでも書けるかもしれないが、とりあえずは置いておいて。

先日Pythonの勉強を始めたのも転職に絡むのだけど、初めて外資系の会社に勤めるので英語の勉強も始めてみた。何から始めるかな?って考えてまずはPodcastを聴くなり海外のドラマなり映画なりを観始めてみた。

単に楽な手段を選んだような気もするけど、ざっと調べた限りでまずは多聴しつつ耳を慣らしてシャドーイングしてくのが良さそうと判断した。

そんな訳で、このエントリーには観たもの聴いたものでも列挙していこうかと。

世間的にはコメディとか青春ものとかが面白くて実生活に近くてオススメ!ってことになってるんだけど、そういうのに面白みを感じないのでなかなか選び辛いのが悩みどころw

あと、動画観始めると他のことやる時間が削られるのでIngressとかポケモンGOとか全くできなくなるのも悩みどころw

==========

耳を慣らす用。分かろうが分かるまいが空いてる時間に聴く。興味のある分野なので良い。

正直、映画としては良くはない。エマ・ワトソントム・ハンクスが出演してるのに残念感。話も特に面白みはない。 ただ、この映画はGoogleをモデルにしていて外資系の雰囲気を感じるのに適してる的なtweetを見たので観てみた。

結論から言うと、外資系の雰囲気を感じるのには適してたかもだけど英語の学習的には???って感じ。とにかく早口な場面が多いし。ただ、これで早口すぎると感じるんだと… orz とはなるので、刺激としては良かったかもしれない。

いま観てる。単純に面白い。というか面白すぎて困るw

Amazon Prime Videoだと日本語字幕が出る(というか英語の字幕にできない)ので、結局はずっと日本語字幕を見てしまってダメなんじゃないかと思ったが、観続けてるとそれなりに頭の中に英語がほんの少し浮かんだりするので少しは効果あるのでは。 ま、ほぼ0からの勉強なんだから何やってもプラスにしかならんはず。

========== 以下は観る予定のもの ==========